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

121–130 of 601 posts

Re: Use one big server

#121

Post by lanstin »

andrepew wrote: post #76
ozim wrote: post #73

Earlier quoted context omitted.

So it does not really work in B2B. I don't really have much to do with contracts - but my company is stating that we have up time of 99.xx%. In terms of contract customers don't care if I have Azure/AWS or I keep my server in the box under the stairs. Yes they do due diligence and would not buy my services if I keep it in shoe box. But then if they loose business they come to me .. I can go after Azure/AWS but I am s…

Depends on scale of B2B. Between enterprises, not as much. Between small businesses, works very well (at least in my experience, we are tiny B2B).

It really varies a lot. I have seen very large lazy sites suddenly pick up a client that wanted RCA for each bad transaction, and suddenly get religion quickly (well quickly as a large org can). Those are precious clients because they force investment into useful directions of availability instead of just new features.

Re: Use one big server

#122

Post by adrianmsmith »

Closi wrote: post #61
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…

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.

That's true, unless you need

(1) Different programming languages e.g. you're written your app in Java but now you need to do something for which the perfect Python library is available.

(2) Different parts of your software need different types of hardware. Maybe one part needs a huge amount of RAM for a cache, but other parts are just a web server. It'd be a shame to have to buy huge amounts of RAM for every server. Splitting the software up and deploying the different parts on different machines can be a win here.

I reckon the average startup doesn't need any of that, not suggesting that monoliths aren't the way to go 90% of the time. But if you do need these things, you can still go the microservices route, but it still makes sense to stick to a single database if at all possible, for consistency and easier JOINs for ad-hoc queries, etc.

Re: Use one big server

#123

Post by ladyattis »

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…

At my current job we have four different databases so I concur with this assessment. I think it's okay to have some data in different DBs if they're significantly different like say the user login data could be in its own database. But anything that we do which is a combination of e-commerce and testing/certification I think they should be in one big database so I can do reasonable queries for information that we need. This doesn't include two other databases we have on-prem which one is a Salesforce setup and another is an internal application system that essentially marries Salesforce to that. It's a weird wild environment to navigate when adding features.

Re: Use one big server

#124

Post by lanstin »

dghlsakjg wrote: post #113
bilekas wrote: post #103

Earlier quoted context omitted.

I can't tell if this is a good thing or a bad thing though! Imagine the clout of saying : "we stayed online while AWS died"

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.

Re: Use one big server

#125

Post by PeterCorless »

We have a different take on running "one big database." At ScyllaDB we prefer vertical scaling because you get better utilization of all your vCPUs, but we still will keep a replication factor of 3 to ensure that you can maintain [at least] quorum reads and writes.

So we would likely recommend running 3x big servers. For those who want to plan for failure, though, they might prefer to have 6x medium servers, because then the loss of any one means you don't take as much of a "torpedo hit" when any one server goes offline.

So it's a balance. You want to be big, but you don't want to be monolithic. You want an HA architecture so that no one node kills your entire business.

I also suggest that people planning systems create their own "torpedo test." We often benchmark to tell maximal optimum performance, presuming that everything is going to go right.

But people who are concerned about real-world outage planning may want to "torpedo" a node to see how a 2-out-of-3-nodes-up cluster operates, versus a 5-out-of-6-nodes-up cluster.

This is like planning for major jets, to see if you can work with 2 of 3 engines, or 1 of 2.

Obviously, if you have 1 engine, there is nothing you can do if you lose that single point of failure. At that point, you are updating your resume, and checking on the quality of your parachute.

Re: Use one big server

#126

Post by lanstin »

kkielhofner wrote: post #81
notjustanymike wrote: post #49

Earlier quoted context omitted.

We may need to update this one, I would definitely fire someone today for buying IBM.

Nobody ever got fired for buying AWS!

The AWS people now are just like the IBM people in the 80s - mastering a complex and not standards based array of products and optional product add-ons. The internet solutions were open and free for a few decades and now it’s AWS SNADS I mean AWS load balancers and edge networks.

Re: Use one big server

#127

Post by robertlagrant »

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…

> 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).

I'm not sure how to parse this. What should "asks" be?

Re: Use one big server

#128

Post by stevenjgarner »

xen2xen1 wrote: post #110
stevenjgarner wrote: post #36

Earlier quoted context omitted.

I have only done a few midwestern states. Call them and ask [0] - (919) 733-7328. You may want to first call your proposed county commissioner's office or city hall (if you are not rural), and ask them who to talk with about a new local business providing Internet service. If you can show the Utilities Commission that you are working with someone at the local level I have found they will treat you more seriously. In…

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 telephone numbering. You can put in your own Asterisk server [0] and provide VoIP service on your burgeoning optical utilities network, together with other bundled services including television, movies, gaming, metering etc.. All of these offerings can be resold from wholesale services, where all you need is an Internet feed.

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.

One potentially valuable thing a utility can do is place empty conduit in public right of way that can be used/resold in the future at a (considerable) gain. For example, before highways, roadways, airports and other infrastructure is built, it is orders of magnitude cheaper just to plow conduit under bare ground before the improvements are placed.

[0] https://www.asterisk.org/

Re: Use one big server

#129

Post by mhoad »

Guid_NewGuid wrote: post #101
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…

I think a strong test a lot of "let's use Google scale architecture for our MVP" advocates fail is: can your architecture support a performant paginated list with dynamic sort, filter and search where eventual consistency isn't acceptable? Pretty much every CRUD app needs this at some point and if every join needs a network call your app is going to suck to use and suck to develop.

I’ve found the following resource invaluable for designing and creating “cloud native” APIs where I can tackle that kind of thing from the very start without a huge amount of hassle https://google.aip.dev/general

The patterns section covers all of this and more

Re: Use one big server

#130

Post by flatiron »

phkahler wrote: post #120
treis wrote: post #53

Earlier quoted context omitted.

I think it's more of a shield against upper management. AWS going down is treated like an act of god rendering everyone blameless. But if it's your one big server that goes down then it's your fault.

>> AWS going down is treated like an act of god rendering everyone blameless. Someone decided to use AWS, so there is blame to go around. I'm not saying if that blame is warranted or not, just that it sounds like a valid thing to say for people who want to blame someone.

“Nobody gets fired for using aws” is pretty big now a days. We use GCP but if they have an issue and it bubbles down to me nobody bats an eye when I say the magical cloud man made ut oh whoopsie and it wasn’t me.
Post reply on HN