QUAL DIFERENÇA | SERVIDOR DE APLICAÇÃO E PRODUÇÃO?

 Tópico anterior Próximo tópico Novo tópico

QUAL DIFERENÇA | SERVIDOR DE APLICAÇÃO E PRODUÇÃO?

VB.NET

 Compartilhe  Compartilhe  Compartilhe
#479512 - 08/02/2018 11:50:46

MARCOS

Cadast. em:Dezembro/2003


Bom dia!
Pessoal, peço o seguinte esclarecimento sobre
um problema de arquitetura  :
Temos na empresa, sistemas feitos em .NET e
Java. ( WEB e WinForms ).

O caso:

Conversando com o setor de infraestrutura da empresa      onde trabalho,
eu divergi de um analista de rede.Como meu conhecimento não é de fato
grande, eu posso estar errado, e por isto peço a opinião dos colegas.

O problema:

Existe diferença entre servidor de aplicação e de produção?

A opinião do colega da infraestrutura:

Ele me disse que servidores de aplicação devem conter somente os arquivos executáveis,etc... referentes a aplicação.
Ou seja, um repositório de arquivos. Mas, se a aplicação tiver que rodar processos no própio servidor (E não no usuário)
estes processos devem ficar em um servidor separado , que é o de produção. Ou seja, ele vê uma clara diferença entre
um e outro.

A minha opinião:

Eu sempre achei que na "prática" , servidor de aplicação e de produção
sejam a mesma coisa.O que sempre achei importante é ( Se possível )
que o sistema tenha um servidor separado, para colocar tanto os arquivos
do projeto (Executáveis,etc..), quanto para rodar processos no própio
servidor referentes a mesma aplicação.

Dúvidas:

1.) Neste caso, Qual a arquitetura é a correta, se o sistema for para  Web ( Um mesmo servidor, ou dois separados ) ?  
2.) Neste caso, Qual a arquitetura é a correta, se o sistema for para  WinForm  ( Um mesmo servidor, ou dois separados )?  


Agradeço qualquer orientação




#479513 - 08/02/2018 12:32:07

F001E
IBITINGA/SP
Cadast. em:Novembro/2004


Não uso WinForm, somente Web.

Nos clientes fazemos assim. Um servidor de aceite e outro servidor de produção. No servidor de aceite é todo teste realizado pelo cliente sobre alguma melhoria e se der algum pau, não ferra a base de produção já que é uma base de teste. No servidor de produção só será atualizado se os teste no servidor de aceite foi realizado com sucesso. Mas independente de ser servidor de aceite ou produção os dois rodam os mesmos processos.

Eu também não entendi direito essa questão de servidor de aplicação e produção que se refere.



Resposta escolhida #479514 - 08/02/2018 12:35:52

WEBMASTER
CURITIBA
Cadast. em:Janeiro/2001


Membro da equipe

Última edição em 08/02/2018 12:39:07 por WEBMASTER

Marcos


Existem várias formas de distribuir aplicação e principalmente de definir uma arquitetura de processos.
Não vamos focar em linguagens ou tecnologias, mas sim no processo.

Se você tem uma aplicação de alta responsividade, aquela que não pode deixar o usuário na mão de jeito nenhum, é muito comum dividir os processos em online e batch , para justamente realizar  a divisão de camadas. Trabalhei em uma empresa do sistema financeira, e lá era muito legal avaliar esse tipo de divisão, os processos online eram em geral servidores dedicados a executar tarefas e em geral repassar conteúdo para outros serviços realizarem pesquisa e devolverem respostas, com uma gama de roteamento e balanceamento de carga, os processos para o 'cliente' rodavam muito rápido, e para os servidores batch a carga era feita sobre demada e escala.

O processo de quebrar sua aplicação em partes (online/batch) lhe dá folego para crescer e demandar hardware a medida que o processo cresce, e com balanceamento de carga, você consegue melhorar muito o tempo de resposta, vendo qual servidor por exemplo está mais sobrecarregado e demandar outro.

Na minha opinião, se você tem condições financeiras e comprova por um estudo de capacity plan que o ideal é ter servidores separados, faça isso, pois você ganha escala a medida que as coisas crescem.
Se você mantiver um servidor único (de novo, não falando de tecnologia, mas sim de processo) e seu processo crescer organicamente a ponto de colocar a performance em risco, o recomendado é trabalhar em paralelo em serviços dedicados para isso em um segundo servidor.

Ou seja, no final das contas o melhor mundo sempre será ter servidores separados, porém em muitos casos um capacity plan não comprova isso de primeira pois você não tem KPIs suficientes para demonstrar os riscos


WebMaster - VBMania

Nao me mande e-mail com duvidas
Para isso e que existe o forum do VBMania !!!

#479515 - 08/02/2018 12:37:16

WEBMASTER
CURITIBA
Cadast. em:Janeiro/2001


Membro da equipe
Citação:
:
Não uso WinForm, somente Web.

Nos clientes fazemos assim. Um servidor de aceite e outro servidor de produção. No servidor de aceite é todo teste realizado pelo cliente sobre alguma melhoria e se der algum pau, não ferra a base de produção já que é uma base de teste. No servidor de produção só será atualizado se os teste no servidor de aceite foi realizado com sucesso. Mas independente de ser servidor de aceite ou produção os dois rodam os mesmos processos.

Eu também não entendi direito essa questão de servidor de aplicação e produção que se refere.


Essa arquitetura que voce comentou entendo eu que estamos falando de desenvolvimento/homologação  e produção, que é diferente do que ele citou, uma vez que como você mesmo diz os dois rodam os mesmos processos

WebMaster - VBMania

Nao me mande e-mail com duvidas
Para isso e que existe o forum do VBMania !!!

#479521 - 08/02/2018 16:31:22

MARCOS

Cadast. em:Dezembro/2003


Pessoal,
Não estou , neste caso nem mesmo considerando o servidor para homologação ( Testes,etc...)

Estou me referindo ao servidor onde meu sistema ( Já testado e homologado ) irá rodar.

O meu colega de redes, defende a idéia que deve-se ter 2 servidores:

1 de "aplicação" ( Para colocar  o executável e demais arquivos do projeto ) e outro "Produção", para rodar os processos que minha aplicação executa , estando ou não o usuário logado.
Ele acredita que estes processos da minha aplicação, rodando no servidor de aplicação o farão "Cair".

Eu , ao contrario. Penso que não existe necessidade de 2 servidores. O mesmo servidor (Aplicação ), pode rodar  processos em Back-Gound da aplicação,e
também ter   os arquivos executáveis que serão executados via atalho nos desktop dos usuários.
Contanto que o servidor, tenha o Hardware dimensionado corretamente para  suportar a demanda,penso que a arquitetura é correta.

Estou Correto na minha avaliação?




#479522 - 08/02/2018 16:40:23

KERPLUNK
RIO GRANDE DO SUL
Cadast. em:Junho/2009


Membro da equipe
O que seu colega de redes parece estar descrevendo é mais ou menos a arquitetura de micro-serviços. As nomenclaturas que estão estranhas. Geralmente "produção" se refere à o ambiente onde a aplicação como um todo roda, incluindo toda a parte de backend e front-end, mesmo que em servidores, instâncias ou containeres separados. A nomenclatura que eu usaria é frontend(o que você se refere como aplicação) e backend(os processos que rodam "por trás"). Pergunte à ele se o que ele se refere é a arquitetura de micro-serviços. Existe também a possibilidade de ele estar se referindo à containeres, mais precisamente um "queridinho" do pessoal de infra e redes, chamado Docker.

_______________________________________________________________________
Gostaria de ter seu sistema Desktop "traduzido" para uma interface web? Podemos conversar...
Virei Oráculo!
The end is nigh, be ready for the nukes!


#479535 - 09/02/2018 11:24:35

WEBMASTER
CURITIBA
Cadast. em:Janeiro/2001


Membro da equipe
Marcos

Os dois pontos de vista são válidos, tanto o seu quanto de seu colega.
A questão que vai definir quem "está certo" é a demanda:
- a sua opção tem maiores chances de alcançar um gargalo rapidamente por tudo se resolver na mesma máquina.
- a opção dele torna o produto escalável, você pode crescer ligando servidores de chamada a qualquer momento

Uma boa forma de você medir isso tudo é por exemplo se perguntar (se você já não tem isso no processo) como seria importar um arquivo gigantesco para a base (digamos que um CSV de mais de 200 mil linhas fosse mandado para o servidor^) e você não tem duas máquinas, quanto tempo de gargalo vai haver (aplicando regras de negócio linha-a-linha desse arquivo)

Interessante como você encerra seu post, Estou Correto na minha avaliação? , eu diria que aqui o que vale não é bem a sua opinião ou a dele, mas sim realizar um stress test, como por exemplo uma atualização massiva no banco , uma queda de um serviço, enfim, simular cenários que demonstrem que um servidor só aguenta perfeitamente, porém com determinados riscos, ou que optando por duas máquinas você terá vários riscos mitigados graças a arquitetura definida.


WebMaster - VBMania

Nao me mande e-mail com duvidas
Para isso e que existe o forum do VBMania !!!

#479549 - 09/02/2018 15:56:20

MARCOS

Cadast. em:Dezembro/2003


Boa tarde,
As respostas dos colegas foram mais que suficientes para esclarecer
minhas dúvidas.No entanto, antes de encerrar o tópico, se for possível
gostaria de fazer mais uma pergunta que esta "ligada" a este mesmo
assunto:

1.) De um modo geral, quais são os erros       mais comuns que os desenvolvedores
     podem cometer ao criar um sistema. Que pode ocasionar a queda ou travamento
     de um servidor?



  



#479551 - 09/02/2018 16:39:00

WEBMASTER
CURITIBA
Cadast. em:Janeiro/2001


Membro da equipe
Marcos

Sem duvida a inexperiencia do desenvolvedor e o que mais contribui para problemas no sistema.

Desenhar cuidadosamente a aplicacao, ao inves de partir diretamente para o codigo, e principalmente entender REAL e EFETIVAMENTE as regras de negocio e necessidade do cliente sao coisas que so se constroi com tempo e com erros e acertos.

Dimensionar uma aplicacao de forma incorreta e um dos maiores pontos de problema das aplicacoes (muito do que debatemos aqui), aliado a isso, fatores externos (legislacao/regra fiscal/etc...) fazem com que seu sistema que estava funcionando bem ate ontem tenha que ser repensado para amanha.

Em geral nao ha formula magica, o que ha sim...eh experiencia, viver os problemas, dividir as vitorias e conquistas e principalmente aprender com os erros.
Hoje a internet facilita milhoes de vezes mais essa acertividade, aliado a isso os custos de hardware nao sao como eram no passado...ou seja, o que faz diferenca eh o individuo (PESSOA) e sua experiencia e visao.


WebMaster - VBMania

Nao me mande e-mail com duvidas
Para isso e que existe o forum do VBMania !!!

#479552 - 09/02/2018 17:12:13

MARCOS

Cadast. em:Dezembro/2003


Muito obrigado a todos pelas respostas.



 Tópico anterior Próximo tópico Novo tópico


Tópico encerrado, respostas não sao permitidas
Encerrado por MARCOS em 09/02/2018 17:12:28