Live data from Hacker News

Choosing Go to implement the new GOV.UK router

gdstechnology.blog.gov.uk

11–20 of 98 posts

Re: Choosing Go to implement the new GOV.UK router

#11
post #3

Not impressed. I have nothing against Go (in fact I like it) but they seem to have built GOV.UK with every damn bit of technology there is available. I've seen Varnish, Go, Ruby, Python, Scala, Java, Mongo, MySQL, nginx, rails, sinatra, Django and PILES of Not Invented Here. Also I'm not sure it's a great use of public money to build stuff like this when they should have nginx/apache up front and some configuration.…

I tend to agree. The post makes a point of saying "we had a router built in scala, but no one on the team knew how to maintain it".

It seems they're allowing team members to play with "language of the week" (lotw), build something that's then used in production without the rest of the team knowing the lotw, that member moving on and then rebuilding it in a new lotw 6 months later. no doubt this GO implementation will go the same way at a later date.

I'm not opposed to using a lotw in production with other languages and such, but it needs to be done in a thought out manner with the whole "what if the project lead gets hit by a big red double decker" mentality.

Re: Choosing Go to implement the new GOV.UK router

#12
post #5
post #3

Not impressed. I have nothing against Go (in fact I like it) but they seem to have built GOV.UK with every damn bit of technology there is available. I've seen Varnish, Go, Ruby, Python, Scala, Java, Mongo, MySQL, nginx, rails, sinatra, Django and PILES of Not Invented Here. Also I'm not sure it's a great use of public money to build stuff like this when they should have nginx/apache up front and some configuration.…

In their defense having worked on sorting out problems on old complex large scale publishers sites. If your trying to make a collection of services hang together in a seamless way you do need some sort of front end to tie it all together and that needs to be usable by non gurus. Though they do seem to be using all the new toys maybe a bit more thought about which technology to use rather than jumping from technology…

Yep I understand that.

We publish several huge legacy applications, several huge new applications, several integrations, public web site, documentation, online support. A mere 80-100 million HTTP transactions a day.

Not once have we built something to do it all.

Re: Choosing Go to implement the new GOV.UK router

#13
post #3

Not impressed. I have nothing against Go (in fact I like it) but they seem to have built GOV.UK with every damn bit of technology there is available. I've seen Varnish, Go, Ruby, Python, Scala, Java, Mongo, MySQL, nginx, rails, sinatra, Django and PILES of Not Invented Here. Also I'm not sure it's a great use of public money to build stuff like this when they should have nginx/apache up front and some configuration.…

It does not look that bad actually. Your list lacks Oracle, Microsoft technologies to really complain about inefficient usage of public money. I would love if my country used open source more.

Re: Choosing Go to implement the new GOV.UK router

#14
post #13
post #3

Not impressed. I have nothing against Go (in fact I like it) but they seem to have built GOV.UK with every damn bit of technology there is available. I've seen Varnish, Go, Ruby, Python, Scala, Java, Mongo, MySQL, nginx, rails, sinatra, Django and PILES of Not Invented Here. Also I'm not sure it's a great use of public money to build stuff like this when they should have nginx/apache up front and some configuration.…

It does not look that bad actually. Your list lacks Oracle, Microsoft technologies to really complain about inefficient usage of public money. I would love if my country used open source more.

Agree entirely there!

However it doesn't excuse people working on a web site funded by the taxpayer using it as a technology playground.

Re: Choosing Go to implement the new GOV.UK router

#15
post #3

Not impressed. I have nothing against Go (in fact I like it) but they seem to have built GOV.UK with every damn bit of technology there is available. I've seen Varnish, Go, Ruby, Python, Scala, Java, Mongo, MySQL, nginx, rails, sinatra, Django and PILES of Not Invented Here. Also I'm not sure it's a great use of public money to build stuff like this when they should have nginx/apache up front and some configuration.…

We did have some configuration - it was stored in Varnish and Nginx. The time cost of shipping new redirects when content is moved or new routing configuration for new tools coming online is non-negligible, particularly as we're in the middle of moving 300+ government agencies onto the GOV.UK platform. Also having all those redirects, friendly URLs, and application mappings in static configuration makes self-service publishing tools very difficult to build.

This is all outlined in the blog post - perhaps not as clearly as I would have liked, though!

Re: Choosing Go to implement the new GOV.UK router

#16
post #8

On the github page it says the router sits between nginx and varnish and does: * Reverse proxy, forwarding requests to and serving responses from multiple backend servers on a single domain. * Redirector, serving HTTP 301 and 302 redirects to new URLs. * Gone responder, serving HTTP 410 responses for resources that used to but no longer exist. Does anyone know why they have this as a separate piece of software instea…

You should read the first article in the series - https://gdstechnology.blog.gov.uk/2013/12/05/building-a-new-...

I actually read that and thought nginx/mod_proxy.

Looks like they didn't actually try it or know about it which is worrying.

Either that or it was more interesting to do it in Go which is not a valid reason in a taxpayer funded site.

Re: Choosing Go to implement the new GOV.UK router

#17
post #3

Not impressed. I have nothing against Go (in fact I like it) but they seem to have built GOV.UK with every damn bit of technology there is available. I've seen Varnish, Go, Ruby, Python, Scala, Java, Mongo, MySQL, nginx, rails, sinatra, Django and PILES of Not Invented Here. Also I'm not sure it's a great use of public money to build stuff like this when they should have nginx/apache up front and some configuration.…

Presumably by having a list of different technologies they are taking the approach of right tool for the job. The obvious side affect also being that engineers who work on this need to be polyglot as opposed to any specific tech. I certainly categorise this as a good thing, a developer and as a stakeholder (UK resident and user of the site).

Re: Choosing Go to implement the new GOV.UK router

#18
A lot of the comments here seem to be missing something quite important: Scala and Go are not similar languages.

Scala is a large and complex language, encompassing multiple programming idioms. Teams programming Scala (as with C++ and many other "large" languages) often have difficulties nailing down what portion of the language they are going to use. "Java-without-semicolons" all the way through to idiomatic, functional Scala.

Go is a relatively small, simple language. You could easily learn Go's basic syntax and semantics in an afternoon or two. Simplicity and suitability for programmers is an explicit design goal.

Switching away from Scala due to lack of experience while simultaneously picking up Go is not as illogical as everyone seems to be implying.

Re: Choosing Go to implement the new GOV.UK router

#19
post #14
post #13

Earlier quoted context omitted.

It does not look that bad actually. Your list lacks Oracle, Microsoft technologies to really complain about inefficient usage of public money. I would love if my country used open source more.

Agree entirely there! However it doesn't excuse people working on a web site funded by the taxpayer using it as a technology playground.

In their defence, gov.uk is miles better than just about any other government site/application I've ever used.

Re: Choosing Go to implement the new GOV.UK router

#20
post #3

Not impressed. I have nothing against Go (in fact I like it) but they seem to have built GOV.UK with every damn bit of technology there is available. I've seen Varnish, Go, Ruby, Python, Scala, Java, Mongo, MySQL, nginx, rails, sinatra, Django and PILES of Not Invented Here. Also I'm not sure it's a great use of public money to build stuff like this when they should have nginx/apache up front and some configuration.…

We did have some configuration - it was stored in Varnish and Nginx. The time cost of shipping new redirects when content is moved or new routing configuration for new tools coming online is non-negligible, particularly as we're in the middle of moving 300+ government agencies onto the GOV.UK platform. Also having all those redirects, friendly URLs, and application mappings in static configuration makes self-service…

They're incredibly easy to build. I notice you use puppet. That's enough tooling to push configuration out and restart services for nginx or apache+mod_proxy. You can break configuration out into separate files per agency if you need to.

Varnish is different as that requires restarting.

We do the same with commercial kit (Riverbed) with over 140 HTTP application endpoints and that is higher friction than the equivalent setup yet we manage it with a mere 1 person...

Deployment is a solved problem. No offense but you're not Google!

Post reply on HN