Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go + Services = One Goliath Project

engineering.khanacademy.org

Post reply on HN
Print view View original

261–270 of 449 posts

Re: Go + Services = One Goliath Project

#261

Post by guitarbill »

stoicShell wrote: post #231
guitarbill wrote: post #212

Earlier quoted context omitted.

the number of failed migrations, modernizations, and "tech transformations" in non-software industries, as well as the number of consulting outfits and their profits doesn't seem to back this up. [0] IT disasters now part of modern life - https://www.afr.com/technology/it-disasters-now-part-of-mode... [1] Number of IT failures at banks and other firms is unacceptable, say MPs - https://www.theguardian.com/business/20…

That will make for some pretty salient readings, thanks for the links. There are obviously cases of failure. I don't know the stats. I'm speaking mostly of small/medium businesses, where size and complexity are different.

that's fair, most of those are "you get what you pay for" and hardly the fault of a competent, well-meaning, but naive dev team. problem is it's much harder to get data on small businesses.

i think one thing we can agree on is that the only thing users hate more than change is breakage.

rewrites are a valid tool in a long-term strategy, just as debt is for finance. but for most people, incremental change has a bigger, smoother RoI. it sounds like this is kind of what KA is doing. although the timeline seems aggressive and the whole thing absolutist, being stuck on Python 2 is a risk now, too.

Re: Go + Services = One Goliath Project

#262

Post by bborud »

purple-again wrote: post #9

We turned our monolith into a bunch of micro services almost 6 years ago to the day. For a long time I was very happy with the new pattern but over the years the weight of keeping everything updated along with the inevitable corners that fall behind and have...questionable..security due to how long they sit neglected has really left me wondering if I am happy with it after all. I would love hear some thoughts from ot…

Start with a monolith that has clear internal APIs that are designed so they can later be made into network APIs. This gives you the development speed of a monolith while maintaining an options for the future. When you do break things out into separate services: try to make as few of them as possible and maintain the ability to build as a monolith.

Forget everything you have heard about micro services. Most of it is bullshit from people who don’t actually think for themselves.

Re: Go + Services = One Goliath Project

#263

Post by WoodTree »

StillBored wrote: post #216
WoodTree wrote: post #163

Earlier quoted context omitted.

They don’t have to be glorified for loops, even if they usually are. Map and Filter should be capable of running in parallel or asynchronously, and some languages provide this.

And many languages, have parallel for constructs. The openmp #pragma parallel extensions in C/C++ for example. Of course its possible to create constructs which provide the messages passing for clustered environments too. And maybe that is part of the problem with a generic 'map' your not really sure the underlying implementation, is it parallel, clustered, serial, etc? So you end up with map(), parallel_map(), mpi_m…

In a functional language those details should be irrelevant. But of course they are relevant in practice, and map is usually just a for loop.

Re: Go + Services = One Goliath Project

#264

Post by thethimble »

RandyRanderson wrote: post #258

Why do they call them "micro services" and not distributed systems? Oh right, it's because distributed systems are obviously really hard to create correctly and no sane person would ever agree to pay for that. Nice: re-branding. I can't wait for the, maybe "consolidated computing" manifesto (aka turning micro services back into monoliths).

What if the services you are writing are independent in that they solve separate business problems, are built by separate teams, have little to no data coupling (e.g. Only basic auth), have different scalability profiles, etc? Separate services are really effective for these cases. Neither micro services nor monoliths are silver bullets. Instead it's possible for each approach to be the best approach in a particular business context.

Re: Go + Services = One Goliath Project

#265

Post by tapirl »

bootlooped wrote: post #115

The article mentions Go's superior compile time, when compared to Kotlin. I have done a lot more Java development than Kotlin, but my recollection is that both of them compiled fairly fast. Is Go really significantly faster to compile for similarly sized projects?

The article mentions why choosing Go over Kotlin is memory consumption.

Re: Go + Services = One Goliath Project

#266

Post by guitarbill »

dangoor wrote: post #244
guitarbill wrote: post #220

Earlier quoted context omitted.

in production is fast startup really such a boon outside of serverless? especially if you're already doing blue/green deployments, doesn't seem like it'll have much impact. (depends what "fast" vs "slow" means - are we talking about milliseconds vs a second or two, or startup times so horrendous they cripple your devs' ability to iterate and tests?)

We essentially run in a serverless environment (App Engine), so fast startup does matter to avoid some unlucky users hitting the cold start.

fair enough. you say in the blog App Engine has worked well for you and you're sticking with it, so i'm assuming you considered moving to traditional servers but found it unappealing?

Re: Go + Services = One Goliath Project

#267

Post by olingern »

RandyRanderson wrote: post #258

Why do they call them "micro services" and not distributed systems? Oh right, it's because distributed systems are obviously really hard to create correctly and no sane person would ever agree to pay for that. Nice: re-branding. I can't wait for the, maybe "consolidated computing" manifesto (aka turning micro services back into monoliths).

Why are you getting hung up on nomenclature? The point of the article is clear. If you feel that using 'microservices' is too trite or "buzzword-y" then that's about you and not the article.

Re: Go + Services = One Goliath Project

#268

Post by dangoor »

guitarbill wrote: post #266
dangoor wrote: post #244

Earlier quoted context omitted.

We essentially run in a serverless environment (App Engine), so fast startup does matter to avoid some unlucky users hitting the cold start.

fair enough. you say in the blog App Engine has worked well for you and you're sticking with it, so i'm assuming you considered moving to traditional servers but found it unappealing?

Yes. Google Cloud now has multiple options for autoscaling servers (App Engine Standard, App Engine Flex, and Cloud Run) with the biggest differences being how they're deployed and specifics around the scaling.

We _could_ manage our own Kubernetes clusters and such, but Cloud Run is pretty similar to that and takes away all of the management headache. There is essentially zero code difference, should we decide to change our deployment strategy later.

We're using Google Cloud Datastore for persistence, and that automatically scales in both servers and storage, so it has worked out nicely for us as well.

Re: Go + Services = One Goliath Project

#269

Post by Sevii »

RandyRanderson wrote: post #258

Why do they call them "micro services" and not distributed systems? Oh right, it's because distributed systems are obviously really hard to create correctly and no sane person would ever agree to pay for that. Nice: re-branding. I can't wait for the, maybe "consolidated computing" manifesto (aka turning micro services back into monoliths).

People are willing to pay for it when you have 50+ engineers trying to push code through one deployment pipeline. There's an inflection point somewhere at which the cost of sharing deployments is no longer worth it.

Re: Go + Services = One Goliath Project

#270

Post by andyroid »

gtirloni wrote: post #233
solidasparagus wrote: post #229

Earlier quoted context omitted.

I don't really understand moving to microservices if you aren't going to give the service teams the autonomy to make their own decisions and move at their own pace. Microservices always seemed to me to be more of an organizational strategy than a technical one - if you have services, but they can't operate independently, it feels a bit like you are just creating a distributed monolith.

Choosing the dependencies' version is not all there's to decide. Teams have a lot of control of basically everything else.

So, no choice of language and no choice of the libraries used. What’s “everything else” exactly? Sounds like missing out on the more interesting parts of a micro service architecture.
Post reply on HN