[go-nuts] Re: How to manage a web portal with multiple services without stopping and restarting everything at each release/fix?
On Sunday, 19 June 2016 09:53:34 UTC+1, Simon Ritchie wrote: > > Whichever you choose, it will not be as good as PHP in some respects and I > predict that speed of redeployment will be one of them. > When deploying to hundreds of servers, deploying hundreds of files to each becomes unmanageable. Facebook solved this by compiling everything into a single binary, which is how Go does things from the onset. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: How to manage a web portal with multiple services without stopping and restarting everything at each release/fix?
On Thursday, 16 June 2016 16:02:50 UTC+1, romano.p...@gmail.com wrote: > > In Layman terms, if I had a portal in php I could (of course it depends on > situations) simply replace the pages of the module for the Service 1 > without the need to stop everything (not only Service 2,3,4 and so on but > the whole portal). > Put a service router in front and make each an independent service [binary]. An example of such infrastructure: https://gdstechnology.blog.gov.uk/2013/12/05/building-a-new-router-for-gov-uk/ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: How to manage a web portal with multiple services without stopping and restarting everything at each release/fix?
I think you will be hard put to match the performance of a PHP application on restart, and it may be faster in general. I've always assumed that this is due in part to the fact that the app is embedded in the web server and in part to the essential simplicity of the framework - PHP doesn't do as much for you as an industrial-strength application server, but what it does do, it does very efficiently. However, now that hardware is cheap and software development remains expensive, we can throw hardware at the performance issue and use frameworks that support rapid and relatively cheap development. It's just a cost benefit equation - over some sensible lifetime, say five years, your app will cost X to develop and maintain, the equipment to run it will cost Y and then Z per year to supply electricity and air conditioning - you pay to heat up the computers, then you pay again to cool them down. If your PHP app can run on less powerful equipment, the running costs will be lower. However, in an app of any complexity, X will be the biggest cost, so that's the one to concentrate on. Testing will be the lion's share of that cost, so you want a framework that supports effective testing. The problem with PHP is the other side of the same coin - simplicity. Other frameworks do more for you, and It's much cheaper to write a reliable, robust and scalable application using something like Go or Java. Java is a very mature product, and so it's easy to find developers who know it. Go is quite immature in comparison but it has all sorts of advantages such as native code generation and rapid garbage collection. My guess is that you are looking at Go because you've reached the point where your PHP app is costing too much to maintain. If I'm wrong that you are in this situation, I think a lot of other people are. Five years ago I would have advised you to look at Java, but now we have Go as well. Whichever you choose, it will not be as good as PHP in some respects and I predict that speed of redeployment will be one of them. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: How to manage a web portal with multiple services without stopping and restarting everything at each release/fix?
Hi Tamás, thanks, I will have a look. I guess and hope that this is what I need. @Simon: thanks for the response with so many details. I have been working for years for projects with load balancers, HA, disaster recovery sites, and so on so your detailed answer can be really helpful to understand the topic for other readers. In my specific case it's not what I was looking for because I am more interested in a modular software architecture that allows me to make modifications in that way, rather than the service one. Thanks. I guess that I will build up my special golang architecture and I hope that the graceful restart pattern is what I need. Cheers! Romano -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: How to manage a web portal with multiple services without stopping and restarting everything at each release/fix?
This is not a question about Go, but basic web infrastructure. However, it's one of those "best practice" questions which "everybody knows the answer to" and so you may be hard put to find out more without knowing where to start. First of all, I should point out that when you tweak your PHP page, that does cause a service outage, but it's very short, and you usually don't notice. The usual solution to this problem is to use a team of web servers behind a load balancer or a reverse proxy. A load balancer is a commercial product and most router manufacturers supply them, Cisco to name but one. You can build your own reverse proxy using the Apache web server. The Apache documentation explains how. A reverse proxy is a web server that stands between the client web browsers and a team of web servers that do the work. The proxy takes each incoming request and sends it to one of the web servers, then relays the response back to the client. it looks to the client that the proxy is its web server, but actually it's just relaying requests and responses. Add the ability to put extra worker servers into the team and take them out and you have your solution. When you want to restart a server, you remove it from the team, restart it and then put it back, so at no time are all the servers out of action. You need to arrange that there are always enough servers to cope with the traffic. If you visit a large website such Google or Amazon, you are almost certainly talking to some sort of reverse proxy with lots of workers behind it. The worker servers are usually called "application servers" , so you have the classic chain of: load balancer, web server, application server. In your case, your Go software will run on the app servers. Access to the app servers should be disallowed by the network except by the web server. One of the advantages of the REST approach to web design is that your servers can be stateless, so each request can be sent to any old server. (With a statefull protocol, the proxy may need to keep track of sessions of associated requests and send all of the request in the session to the same worker.) It's also common to terminate any SSL connections at the web server, ie the clients communicate with the web server via HTTPS, but it communicates with the app servers via HTTP. Being encrypted, HTTPS requires significant extra work and Apache, in particular, is very good at this. A load balancer is a reverse proxy with lots of extra features. In particular it may have more than one connection to the internet, so if there is a problem with one of the connections, it will still work. Load balancers themselves can be more than one machine working as a team, possibly on different sites. By spending (a lot) more money you can increase the reliability of your web service by having equipment in separate buildings on separate sites with a distributed load balancer network, Internet connections from different providers coming into different parts of the buildings and arriving at your equipment via different physical routes, multiple redundant uninterruptable power supplies, backup diesel generators, and so on. One organisation I worked for ran two buildings, one on each side of London, both staffed and each with enough equipment to provide the web service single-handed. The thinking was that there was small chance of one building being destroyed by war, flood, fire or a plane crash. They switched the production service between the buildings regularly to make sure that everything still worked. This is not a cheap solution, but they were in the banking sector and they could afford it. On the more affordable side, cloud services often provide a load balancer as part of the mix. This is general web infrastructure wisdom and nothing to do with Go, so let's not let this discussion run on. There should be enough above to help you choose the right Google searches. Unless anybody thinks that what I've written contains any major blunders, let's all get back to talking about Go. (If anybody wants to contact me directly for help with this sort of stuff, I'm a contractor and my daily rate is only slightly heinous.) Hoping that this helps. Simon On Thursday, June 16, 2016 at 4:02:50 PM UTC+1, romano.p...@gmail.com wrote: > > Hi All, > > Forgive me if I posted in the wrong group, as it could be more of a > question related to design patterns rather than to golang itself. > > *The context* > Imagine to create a full portal with users, profiles, ... and multiple > services that can be activated for different customers. > I can organise the code of my portal in modules so to have a "quite" clear > use of golang packages, but at the end of the day I get to a unique EXE > file that represents my server/portal. > > When I start it, the portal runs. Perfect. > > To make an example, think of google, where you have Drive (Service 1) and > Gmail
