App Ambiente : Cosa preferiscono ora i nostri sviluppatori di rotaie

by Elixir Consultant

• 0
• 3.6K
• Uncategorized

App Ambiente : Cosa preferiscono ora i nostri sviluppatori di rotaie

Sviluppatori di rotaie – Discussione sull’ambiente

Gli sviluppatori di rotaie vogliono sempre fare le cose con stile. È sempre stata una domanda classica, che cosa fa bene agli sviluppatori di Ruby on Rails: AWS o Heroku. La stessa discussione si sta svolgendo nella nostra azienda, tra gli sviluppatori di Rails Developers da un po’ di tempo e potrei dire che questo è un dibattito senza fine. Ma lavorando con diversi sviluppatori di Ruby on Rails provenienti da background ed esperienze diverse, ho potuto vedere alcuni modelli di punti che venivano scambiati nelle discussioni. Sto cercando di consolidare questi punti comuni in questo post del blog.

Sviluppatori di rotaie – AWS VS HEROKU

In primo luogo lascia capire il fatto che il confronto tra AWS e Heroku non è un confronto mela a mela. AWS è IaaS (Infrastructure as a Service) e Heroku è PaaS (Platform as a Service). Qual è la differenza? IaaS offre una serie di componenti di cui uno sviluppatore ha bisogno per costruire un’applicazione su di essa. PaaS offre un ambiente pronto per la distribuzione, dove lo sviluppatore deve spostare il codice insieme a minime modifiche di configurazione per far funzionare l’applicazione. IaaS ha bisogno di più abilità per il deploy, ma il PaaS consente allo sviluppatore di concentrarsi maggiormente solo sul codice.
AWS ha in realtà un’offerta PaaS: “Elastic Beanstalk”, che supporta Ruby, Node.js, PHP, Python, .NET e Java, ma la maggior parte della folla salta altrimenti tenendo AWS PaaS fuori discussione/confronto per ora.

Componenti dell’ambiente – Rails Developer View:

Dal punto di vista dello sviluppatore di Ruby on Rails, usano principalmente i seguenti componenti.
AWS riguarda le istanze di EC2, S3, Load Balancer, Cache Layer, Apache, Passenger, Ruby, Ruby, Rails, PostgreSql….cosa no, qualunque cosa uno sviluppatore di Ruby on Rails abbia bisogno per lo sviluppo/distribuzione, da configurare individualmente. Infine lo sviluppatore di Ruby on Rails deve implementare un sistema di distribuzione come Capistrano e molto altro ancora sul sistema di logging.
Heroku, beh, non si tratta di configurare i singoli componenti. Rails Developers deve fare poche righe di codice nell’applicazione, fare i componenti aggiuntivi necessari, fare un git-push; tutto qui.

Orizzonte della sicurezza – Vista dello sviluppatore delle rotaie:

In AWS per lo più gli aggiornamenti di sicurezza e la patch consiste nel farlo manualmente da Rails Developer quando e dove richiesto. C’è una buona probabilità che questa attività sia gestita male e che i server di produzione siano ben al di sotto degli aggiornamenti di sicurezza. Con Heroku, gli aggiornamenti di sicurezza sono di proprietà della piattaforma ma non dei Rails Developer. Ci sono opinioni contrastanti sul fatto che Heroku è il proprietario della responsabilità e ci sono casi in cui l’attività va contro il codice distribuito, ma di sicuro questo toglie molti mal di testa agli sviluppatori di rotaie.

Scalatura dell’applicazione – Rails Developer View:

Ho spiegato come generalmente uno sviluppatore di Ruby on Rails implementa l’ambiente nel confronto IaaS vs PaaS di cui sopra. Approssimativamente, l’applicazione ha un Procfile, che ha linee del form dyno_type: command_to_run, quindi per esempio (si veda http://devcenter.heroku.com/articles/process-model):
web: bundle exec rails server worker: bundle exec rake jobs:work
Questo, con un:
heroku scala web:4 lavoratore:15
si tradurrà in voi con 4 dinos web e 15 dinos di lavoratori in esecuzione. Si noti che il web è un tipo speciale dyno, che ha accesso al mondo esterno, ed è dietro il loro bel web traffic multiplexer che indirizzerà il traffico di conseguenza.

Fattore di costo:

Ancora una volta non è giusto confrontare l’AWS e Heroku sul fattore di costo. Anche se il costo dell’utilizzo dell’ambiente Heroku è del 100% più costoso dell’AWS, la quantità di tempo e di sforzi necessari è più importante per EC2 a Dyno. Probabilmente non è irragionevole considerare un dyno come un po’ come una micro istanza di EC2. Ma il tempo e lo sforzo richiesto allo sviluppatore di Ruby on Rails per costruire un ambiente sopra un’offerta IaaS per portarlo allo standard PaaS non è sicuramente economico e facile. Accordiamoci anche sui costi associati alla manodopera necessaria per la creazione e la manutenzione di un ambiente.

Conclusione:

Sia Heroku che AWS sono piattaforme eccellenti. Gli sviluppatori di Ruby on Rails vogliono concentrarsi più sul “Codice” che sull’ambiente, quindi la maggior parte di loro preferisce lavorare su Heroku per lo sviluppo, i test, la messa in scena e la produzione dell’applicazione di partenza. Ma per “Serious Production Deployment” con diversi clienti paganti con un’installazione complessa dell’applicazione, con uno SLA da mantenere, con tempo dedicato da dedicare a Dev-Ops ecc. non può portare gli sviluppatori di Rails a scaricare tutto questo controllo su Heroku, e quindi AWS sarebbe la scelta giusta. La piattaforma vincente può essere AWS o Heroku, quella che più aiuta gli sviluppatori di Rails a raggiungere gli obiettivi, li mantiene felici e produttivi, pur rimanendo abbastanza accessibile per essere sostenibile. Sviluppatori di rotaie – Happy Coding !!!!!!