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

Use one big server

specbranch.com

Post reply on HN
Print view View original

331–340 of 601 posts

Re: Use one big server

#331

Post by fleddr »

Our industry summarized:

Hardware engineers are pushing the absolute physical limits of getting state (memory/storage) as close as possible to compute. A monumental accomplishment as impactful as the invention of agriculture and the industrial revolution.

Software engineers: let's completely undo all that engineering by moving everything apart as far as possible. Hmmm, still too fast. Let's next add virtualization and software stacks with shitty abstractions.

Fast and powerful browser? Let's completely ignore 20 years of performance engineering and reinvent...rendering. Hmm, sucks a bit. Let's add back server rendering. Wait, now we have to render twice. Ah well, let's just call it a "best practice".

The mouse that I'm using right now (an expensive one) has a 2GB desktop Electron app that seems to want to update itself twice a week.

The state of us, the absolute garbage that we put out, and the creative ways in which we try to justify it. It's like a mind virus.

I want my downvotes now.

Re: Use one big server

#332

Post by [deleted] »

lanstin wrote: post #124
dghlsakjg wrote: post #113

Earlier quoted context omitted.

Depends on how technical your customer base is. Even as a developer I would tend not to ascribe too much signal to that message. All it tells me is that you don't use AWS. "We stayed online when GCP, AWS, and Azure go down" is a different story. On the other hand, if those three go down simultaneously, I suspect the state of the world will be such that I'm not worried about the internet.

I would expect there are BGP issues that could do that, at least for large swaths of the internet.

[deleted]

Re: Use one big server

#333

Post by wefarrell »

Mavvie wrote: post #293
wefarrell wrote: post #218

Earlier quoted context omitted.

"Your product asks will consistently want to combine these data sources (they don't know how your distributed databases look, and oftentimes they really do not care)." This isn't a problem if state is properly divided along the proper business domain and the people who need to access the data have access to it. In fact many use cases require it - publicly traded companies can't let anyone in the organization access f…

"combine these data sources" doesn't necessarily mean data analytics. Just as an example, it could be something like "show a badge if it's the user's birthday", which if you had a separate microservice for birthdays would be much harder than joining a new table.

Replace "people" with "features" and my comment still holds. As software, features, and organizations become more complex the core feature data becomes a smaller and smaller proportion of the overall state and that's when microservices and separate data stores become necessary.

Re: Use one big server

#334

Post by Rantenki »

lmm wrote: post #315
cfors wrote: post #56

Yep, there's a premium on making your architecture more cloudy. However, the best point for Use One Big Server is not necessarily running your big monolithic API server, but your database. Use One Big Database. Seriously. If you are a backend engineer, nothing is worse than breaking up your data into self contained service databases, where everything is passed over Rest/RPC. Your product asks will consistently want t…

If you do this then you'll have the hardest possible migration when the time comes to split it up. It will take you literally years, perhaps even a decade. Shard your datastore from day 1, get your dataflow right so that you don't need atomicity, and it'll be painless and scale effortlessly. More importantly, you won't be able to paper over crappy dataflow. It's like using proper types in your code: yes, it takes a b…

This is true IFF you get to the point where you have to split up.

I know we're all hot and bothered about getting our apps to scale up to be the next unicorn, but most apps never need to scale past the limit of a single very high-performance database. For most people, this single huge DB is sufficient.

Also, for many (maybe even most) applications, designated outages for maintenance are not only acceptable, but industry standard. Banks have had, and continue to have designated outages all the time, usually on weekends when the impact is reduced.

Sure, what I just wrote is bad advice for mega-scale SaaS offerings with millions of concurrent users, but most of us aren't building those, as much as we would like to pretend that we are.

I will say that TWO of those servers, with some form of synchronous replication, and point in time snapshots, are probably a better choice, but that's hair-splitting.

(and I am a dyed in the wool microservices, scale-out Amazon WS fanboi).

Re: Use one big server

#335

Post by jethro_tell »

threeseed wrote: post #312
manigandham wrote: post #200

Earlier quoted context omitted.

Why would you break apart a microservice? Any why do you need to use/split into microservices anyway? 99% of apps are best fit as monolithic apps and databases and should focus on business value rather than scale they'll never see.

> 99% of apps are best fit as monolithic apps and databases and should focus on business value rather than scale they'll never see You incorrectly assume that 99% of apps are building these architectures for scalability reasons. When in reality it's far more for development productivity, security, use of third party services, different languages etc.

reliability, sometimes sharding just means you don't have to get up in the middle of the night.

Re: Use one big server

#336

Post by lmm »

riku_iki wrote: post #329
lmm wrote: post #315

Earlier quoted context omitted.

If you do this then you'll have the hardest possible migration when the time comes to split it up. It will take you literally years, perhaps even a decade. Shard your datastore from day 1, get your dataflow right so that you don't need atomicity, and it'll be painless and scale effortlessly. More importantly, you won't be able to paper over crappy dataflow. It's like using proper types in your code: yes, it takes a b…

> Shard your datastore from day 1 what about using something like cocroach from day 1?

I don't know the characteristics of bikesheddb's upstream in detail (if there's ever a production-quality release of bikesheddb I'll take another look), but in general using something that can scale horizontally (like Cassandra or Riak, or even - for all its downsides - MongoDB) is a great approach - I guess it's a question of terminology whether you call that "sharding" or not. Personally I prefer that kind of datastore over an SQL database.

Re: Use one big server

#338

Post by jethro_tell »

AtNightWeCode wrote: post #210
Closi wrote: post #61

Earlier quoted context omitted.

Breaking apart a stateless microservice and then basing it around a giant single monolithic database is pretty pointless - at that stage you might as well just build a monolith and get on with it as every microservice is tightly coupled to the db.

Agree. Nothing worse than having different programs changing data in the same database. The database should not be an integration point between services.

if you have multiple micro services updating the database you need to have a database access layer service as well.

there's some real value with abstraction and microservices but you can try to run them against a monolithic database service

Re: Use one big server

#339

Post by eek2121 »

stevenjgarner wrote: post #128
xen2xen1 wrote: post #110

Earlier quoted context omitted.

What other benefits are there to being a "public telecommunication utility"?

The benefit that is obvious to the regulators is that you can charge money for services. So for example, offering telephone services requires being a LEC (local exchange carrier) or CLEC (competitive local exchange carrier). But even telephone services have become considerably unregulated through VoIP. It's just that at some point, the VoIP has to terminate/interface with a (C)LEC offering real dial tone and telephon…

> Other benefits to being a "public telecommunication utility" include the competitive right to place your own facilities on telephone/power poles or underground in public right-of-way under the Telecommunications Act of 1996. You will need to enter into and pay for a pole attachment agreement. Of course local governments can reserve the right to tariff your facilities, which has its own ugliness.

Note that in many parts of the country, the telcos/cablecos themselves own the poles. Google had a ton of trouble with AT&T in my state thanks to this. They lost to AT&T in court and gave up.

Re: Use one big server

#340

Post by lmm »

Rantenki wrote: post #334
lmm wrote: post #315

Earlier quoted context omitted.

If you do this then you'll have the hardest possible migration when the time comes to split it up. It will take you literally years, perhaps even a decade. Shard your datastore from day 1, get your dataflow right so that you don't need atomicity, and it'll be painless and scale effortlessly. More importantly, you won't be able to paper over crappy dataflow. It's like using proper types in your code: yes, it takes a b…

This is true IFF you get to the point where you have to split up. I know we're all hot and bothered about getting our apps to scale up to be the next unicorn, but most apps never need to scale past the limit of a single very high-performance database. For most people, this single huge DB is sufficient. Also, for many (maybe even most) applications, designated outages for maintenance are not only acceptable, but indus…

> I know we're all hot and bothered about getting our apps to scale up to be the next unicorn, but most apps never need to scale past the limit of a single very high-performance database. For most people, this single huge DB is sufficient.

True if the reliability is good enough. I agree that many organisations will never get to the scale where they need it as a performance/data size measure, but you often will grow past the reliability level that's possible to achieve on a single node. And it's worth saying that the various things that people do to mitigate these problems - read replicas, WAL shipping, and all that - can have a pretty high operational cost. Whereas if you just slap in a horizontal autoscaling datastore with true master-master HA from day 1, you bypass all of that trouble and just never worry about it.

> Also, for many (maybe even most) applications, designated outages for maintenance are not only acceptable, but industry standard. Banks have had, and continue to have designated outages all the time, usually on weekends when the impact is reduced.

IME those are a minority of applications. Anything consumer-facing, you absolutely do lose out (and even if it's not a serious issue in itself, it makes you look bush-league) if someone can't log into your system at 5AM on Sunday. Even if you're B2B, if your clients are serving customers then they want you to be online whenever their customers are.

Post reply on HN