Hacker Newsnew | past | comments | ask | show | jobs | submit | sanderjd's commentslogin

Yep! The biggest win for me when AWS came out was that I could self-serve what I needed and put it on a credit card, rather than filing a ticket and waiting some number of days / weeks / months to get a new VM approved and deployed.

This space of #2 like Lithus is not something I'm very familiar with, so thank you for the comment that piqued my interest!

If you're willing to share, I'm curious who else you would describe as being in this space.

My last decade and a half or so of experience has all been in cloud services, and prior to that it was #3 or #4. What was striking to me when I went to the Lithus website was that I couldn't figure out any details without hitting a "Schedule a Call" button. This makes it difficult for me to map my experiences in using cloud services onto what Lithus offers. Can I use terraform? How does the kubernetes offering work? How does the ML/AI data pipelines work? To me, it would be nice if I could try it out in a very limited way as self-service, or at least read some technical documentation. Without that, I'm left wondering how it works. I'm sure this is a conscious decision to not do this, and for good reasons, but I thought I'd share my impressions!


Hello! I think this is a fair question, and improving the communication on the website is something that is steadily climbing up our priority list.

We're not really that kind of product company; we're more of a services company. What we do is deploy Kubernetes clusters onto bare metal servers. That's the core technical offering. However, everything beyond that is somewhat per-client. Some clients need a lot of compute. Some clients need a custom object storage cluster. Some clients need a lot of high-speed internal networking. Which is why we prefer to have a call to figure out specifically what your needs are. But I can also see how this isn't necessarily satisfying if you're used to just grabbing the API docs and having a look around.

What we will do is take your company's software stack and migrate it off AWS/Azure/Google and deploy it onto our new infrastructure. We will then become (or work with) your DevOps team to supporting you. This can be anything from containerising workloads to diagnosing performance issues to deploying a new multi-region Postgres cluster. Whatever you need done on your hardware that we feel we can reasonably support. We are the ones on-call should NATS fall over at 4am.

Your team also has full access to the Kubernetes cluster to deploy to as you wish.

I think the pricing page is the most concrete thing on our website, and it is entirely accurate. If you were to phone us and say, "I want that exact hardware," we would do it for you. But the real value we also offer is in the DevOps support we provide, actually doing the migration up-front (at our own cost), and being there working with your team every week.


This makes total sense to me. I'm thinking through the flow that would lead me to be a customer of yours.

In my current job, I think we're honestly a bit past the phase where I would want to take on a migration to a service like yours. We already have a good team of infrastructure folks running our cloud infrastructure, and we have accepted the lock-in of various AWS managed services. So the high-touch devops support doesn't sound that useful to me (we already have people who are good at this), and replacing all the locked-in components seems unlikely to have good ROI. I think we'd be more likely to go straight to #3 if we decided to take that on to save money.

But I'll probably be a founder or early employee at a new startup again someday, and I'm intrigued by your offering from that perspective. But it seems pretty clear to me that I shouldn't call you up on day 1, because I'm going to be nowhere near $5k a month, and I want to move faster than calling someone up to talk about my needs. I want to self-serve a small amount of usage, and cloud services seem really great for that. But this is how they get you! Once you've started with a particular cloud service, it's always easiest to take on more lock-in.

At some point between these two situations, though, I can see where your offering would be great. But the decision point isn't all that clear to me. In my experience, by the time you start looking at your AWS bill and thinking "crap, that seems pretty expensive", you have better things to do than an infrastructure migration, and you have taken on some lock-in.

I do like the idea of high-touch services to solve the breaking-the-lock-in challenge! I'll certainly keep this in mind next time I find myself in this middle ground where the cloud starts feeling more expensive than it's worth, but we don't want to go straight to #3.


Is it though? This is a genuine question. My intuition is that the investment of time / stress / risk to become good at this is unlikely to have high ROI to either the person putting in that time or to the business paying them to do so. But maybe that's not right.

It's more nuanced for sure than my pithy comment suggests. I've done both self-managed and managed and felt it was a good use of my time to self-manage given the size of the organizations, the profile of the workloads and the cost differential. There is a whole universe of technology businesses that do not earn SV/FAANG levels of ROI - for them, self-managed is a reasonable allocation of effort.

One point to keep in mind is that the effort is not constant. Once you reach a certain level of competency and stability in your setup, there is not much difference in time spent. I also felt that self-managed gave us more flexibility in terms of tuning.

My final point is that any investment in databases whether as a developer or as an ops person is long-lived and will pay dividends for a longer time than almost all other technologies.


I feel like you and I have similar experiences, but have drawn entirely opposite conclusions from them :)

Managing the PostgreSQL databases is a medium to low complexity task as I see it.

Take two equivalent machines, set up with streaming replication exactly as described in the documentation, add Bacula for backups to an off-site location for point-in-time recovery.

We haven't felt the need to set up auto fail-over to the hot spare; that would take some extra effort (and is included with AWS equivalents?) but nothing I'd be scared of.

Add monitoring that the DB servers are working, replication is up-to-date and the backups are working.


> We haven't felt the need to set up auto fail-over to the hot spare; that would take some extra effort (and is included with AWS equivalents?) but nothing I'd be scared of.

this part is actually scariest, since there are like 10 different 3rd party solutions of unknown stability and maintanability.


I think if something like that is worrisome, I'd contact a PostgreSQL consultant for advice.

AWS charge about $500/month for this, so there's plenty of room to pay a consultant and still come out way ahead.


> Managing the PostgreSQL databases is a medium to low complexity task as I see it.

Same here. But, I assume you have managed PostgreSQL in the past. I have. There are a large number of people software devs who have not. For them, it is not a low complexity task. And I can understand that.

I am a software dev for our small org and I run the servers and services we need. I use ansible and terraform to automate as much as I can. And recently I have added LLMs to the mix. If something goes wrong, I ask Claude to use the ansible and terraform skills that I created for it, to find out what is going on. It is surprisingly good at this. Similarly I use LLMs to create new services or change configuration on existing ones. I review the changes before they are applied, but this process greatly simplifies service management.


> Same here. But, I assume you have managed PostgreSQL in the past. I have. There are a large number of people software devs who have not. For them, it is not a low complexity task. And I can understand that.

I'd say needing to read the documentation for the first time is what bumps it up from low complexity to medium. And then at medium you should still do it if there's a significant cost difference.


You can ask an AI or StackOverflow or whatever for the correct way to start a standby replica, though I think the PostgreSQL documentation is very good.

But if you were in my team I'd expect you to have read at least some of the documentation for any service you provision (self-hosted or cloud) and be able to explain how it is configured, and to document any caveats, surprises or special concerns and where our setup differs / will differ from the documented default. That could be comments in a provisioning file, or in the internal wiki.

That probably increases our baseline complexity since "I pressed a button on AWS YOLO" isn't accepted. I think it increases our reliability and reduces our overall complexity by avoiding a proliferation of services.


But is there a significant cost difference? I'm skeptical.

I hope this is the correct service, "Amazon RDS for PostgreSQL"? [1]

The main pair of PostgreSQL servers we have at work each have two 32-core (64-vthread) CPUs, so I think that's 128 vCPU each in AWS terms. They also have 768GiB RAM. This is more than we need, and you'll see why at the end, but I'll be generous and leave this as the default the calculator suggests, which is db.m5.12xlarge with 48 vCPU and 192GiB RAM.

That would cost $6559/month, or less if reserved which I assume makes sense in this case — $106400 for 3 years.

Each server has 2TB of RAID disk, of which currently 1TB is used for database data.

That is an additional $245/month.

"CloudWatch Database Insights" looks to be more detailed than the monitoring tool we have, so I will exclude that ($438/month) and exclude the auto-failover proxy as ours is a manual failover.

With the 3-year upfront cost this is $115000, or $192000 for 5 years.

Alternatively, buying two of yesterday's [2] list-price [3] Dell servers which I think are close enough is $40k with five years warranty (including next-business-day replacement parts as necessary).

That leaves $150000 for hosting, which as you can see from [4] won't come anywhere close.

We overprovision the DB server so it has the same CPU and RAM as our processing cluster nodes — that means we can swap things around in some emergency as we can easily handle one fewer cluster node, though this has never been necessary.

When the servers are out of warranty, depending on your business, you may be able to continue using them for a non-prod environment. Significant failures are still very unusual, but minor failures (HDDs) are more common and something we need to know how to handle anyway.

[1] https://calculator.aws/#/createCalculator/RDSPostgreSQL

[2] https://news.ycombinator.com/item?id=46899042

[3] There are significant discounts if you order regularly, buy multiple servers, or can time purchases when e.g. RAM is cheaper.

[4] https://www.voxility.com/colocation/prices


For what it's worth, I have also managed my own databases, but that's exactly why I don't think it's a good use of my time. Because it does take time! And managed database options are abundant, inexpensive, and perform well. So I just don't really see the appeal of putting time into this.

If you have a database, you still have work to do - optimizing, understanding indexes, etc. Managed services don't solve these problems for you magically and once you do them, just running the db itself isn't such a big deal and it's probably easier to tune for what you want to do.

Absolutely yes. But you have to do this either way. So it's just purely additive work to run the infrastructure as well.

I think if it were true that the tuning is easier if you run the infrastructure yourself, then this would be a good point. But in my experience, this isn't the case for a couple reasons. First of all, the majority of tuning wins (indexes, etc.) are not on the infrastructure side, so it's not a big win to run it yourself. But then also, the professionals working at a managed DB vendor are better at doing the kind of tuning that is useful on the infra side.


Maybe, but you're paying through the nose continually for something you could learn to do once - or someone on your team could easily learn with a little time and practice. Like, if this is a tradeoff you want to make, it's fine, but at some point learning that 10% more can halve your hosting costs so it's well worth it.

It's not the learning, it's the ongoing commitment of time and energy into something that is not a differentiator for the business (unless it is actually a database hosting business).

I can see how the cost savings could justify that, but I think it makes sense to bias toward avoiding investing in things that are not related to the core competency of the business.


How do you manage availability zones in your fully self managed setup?

This sounds medium to high complexity to me. You need to do all those things, and also have multiple people who know how to do them, and also make sure that you don't lose all the people who know how to do them, and have one of those people on call to be able to troubleshoot and fix things if they go wrong, and have processes around all that. (At least if you are running in production with real customers depending on you, you should have all those things.)

With a managed solution, all of that is amortized into your monthly payment, and you're sharing the cost of it across all the customers of the provider of the managed offering.

Personally, I would rather focus on things that are in or at least closer to the core competency of our business, and hire out this kind of thing.


You are right. Are you actually seriously considering whether to go fully managed or self managed at this point? Pls go AWS route and thank me later :)

No not at all, I have the same opinion as you! But I'm curious to understand the opposite view.

I ran through roughly our numbers here [1], it looks like self-hosted costs us about 25% of AWS.

I didn't include labour costs, but the self-hosted tasks (set up of hardware, OS, DB, backup, monitoring, replacing a failed component which would be really unusual) are small compared to the labour costs of the DB generally (optimizing indices, moving data around for testing etc, restoring from a backup).

[1] https://news.ycombinator.com/item?id=46910521


Yes thank you for that. I always feel like these up front cost analyses miss (or underrate) the ongoing operational cost to monitor and be on call to fix infrastructure when problems occur. But I do find it plausible that the cost savings are such that this can be a wise choice nonetheless.

A tricky thing on this site is that there are lots of different people with very different kinds of experience, which often results in people talking past each other. A lot of people here have experience as zero-to-one early startup engineers, and yep, I share your experience that Heroku was very popular in that space. A lot of other people have experience at later growth and infrastructure focused startups, and they have totally different experiences. And other people have experience as SREs at big tech, or doing IT / infrastructure for non-tech fortune 500 businesses. All of these are very different experiences, and very different things have been popular over the last couple decades depending on which kind of experience you have.

Absolutely true but I also think it’s a fair callout when the intent was to disprove the original post asking how old someone was because 15 years ago everyone was stringing together their own services which is absolutely not true. There were many shades of gray at that time both in my experience of either have a sysops/devops team to help or deploying to Heroku as well as folks that were indeed stringing together services.

I find it equally disingenuous to suggest that Heroku was only for startups with lavish budgets. Absolutely not true. That’s my only purpose here. Everyone has different experiences but don’t go and push your own narrative as the only one especially when it’s not true.


I kind of thought the "15 years" was just one of those things where people kind of forget what year it is. Wow, 2010 was already over 15 years ago?? That kind of mistake. I think this person was thinking pre-2005. I graduated college just after that, and that's when all this cloud and managed services stuff was just starting to explode. I think it's true that before that, pretty much everyone was maintaining actual servers somewhere. (For instance, I helped out with the physical servers for our CS lab some when I was in college. Most of what we hosted on those would be easier to do on the cloud now, but that wasn't a thing then.)

I relate to this. But also, isn't it just that every human endeavor goes through an evolution from craft to commodity, which is sad for the craftsmen but good for everyone else, and that we happen to be the ones living through that for software?

For instance, I think about the pervasive interstate overpass bridge. There was a time long ago when building bridges was a craft. But now I see like ten of these bridges every day, each of which is better - in the sense of how much load they can support and durability and reliability - than the best that those craftsmen of yore could make.

This doesn't mean I'm in any way immune to nostalgia. But I try to keep perspective, that things can be both sad and ultimately good.


there is a presumption that the models we are using today are 'good enough'. by models I mean thinks like linkers and package managers, micro services and cluster management tools.

I personally think that we're not done evolving really, and to call it quits today would leave alot of efficiency and productivity on the table


If you're only building things that have been built before, then sure, though I'd argue we already had solutions for that before LLMs.

There's a pretty big generational divide on this point, I think. I don't think many people under the age of 45 or so still see the "never took a sick day" thing as a laudatory statement.

(Also probably a regional divide too. I worry that I'm wrong about this when it comes to some places on the coasts, but I think it's accurate for most places in the country.)


Anecdotally (under 45; American), I agree that "never took a sick day" is indeed not a laudatory statement, but I also strongly believe that working hard is a prime virtue.


That's good news. Hope the kids fight for some basic worker's rights.


I mean, in my career (coming up on 20 years), I've never had an employer that gave me a hard time for taking time off. YMMV I guess!


How many days off do you take per year? For context we get ~43 legally protected paid days of leave per year in Australia, sounds like the UK is about the same.


I was looking for I Think You Should Leave, which I think is great. But it might be the exception that proves the rule, at least for newish shows in the US.

Key and Peele and Chappelle's Show were also this kind of show, but are pretty old now.


No way. Everyone hates Walter at the end. If he had plausibly maintained the "I was doing it for my family" pose, then maybe, yeah. But the whole point of the last season was putting that idea to bed, demonstrating that it was always destructive selfishness.


Yes rationally he should be hated, it just doesn’t appear he is from a lot of discussions and forums online.


It's just not gonna generate a lot of discussion to say "the intended interpretation of the character is correct". The reason Skylar gets a lot of discussion is that there's a lot of disagreement on the interpretation of that character.


It’s less silence and more open, carefully qualified adulation.


On that topic, I think the perspective you're replying to is cope. It would have been better for everyone (else) involved if he took the money from his smarmy friend, took the abuse from his dick boss at his second job, took the abuse from his asshole rich student, took the subtle jabs from his family. Generally, if he swallowed his pride.

Of course, the whole reason the show had a plot is that he was too proud, too toxically masculine, to go that route. And I think the show's implicit thesis is that self-immolating as Walter did was preferable to enduring the indignity of his life. Certainly, it was more fun for the audience.

This is contrary to you and GP, making the (what I observe to be) common assertion that the show is a parable about the danger of toxic masculinity, and anyone who doesn't believe this is too stupid, sexist, or both to "get it" (parenthetically, where you differ I agree with you - people who think Walter is cool and Skylar annoying are legion). The reason I'm calling this "cope" is that reading the show as a morality play condemning toxic masculinity allows one to enjoy it without guilt. This is moral art! If only all that human filth on the internet were smart enough to realize it!

I just don't buy it, though. I think the show is about how being a monster is cooler than being responsible, in large part because all the people who depend on you to be responsible are so damn annoying.


It's not about masculinity at all, it's just "pride comes before the fall". That is not gendered. Both men and women are entirely capable of being destructively prideful. The reason Walter is a villain is that his prideful destruction isn't merely a self-destruction. He also tears apart a bunch of other lives, including those of his wife and children. Again, I'm sorry, but gender isn't the issue with this, if it were a woman who carved a path of destruction through her family and community, she would also be a villain. (And of course these stories exist too.)

The binary options you've proposed to somewhat vindicate Walter's choices were not the only options available to him. The whole point is that he's so brilliant that he can take over a whole regional drug trade in like a year. Well I'm sorry, but if he could do that, he could also have put his brilliance toward some other wildly successful business venture that would not have required blowing people up and putting his family in danger from like three different gangs of violent criminals. There were other options besides eating shit from his rich friend and boss.

He did what he did because he liked it, and he's responsible for the damage that did to the people around him.


Hmm. Well.

I'll admit I gendered it because that's the discourse I always see.

But anyway - you're speaking to whether Walter's actions were moral. I'm more interested in what is the show's attitude towards his actions. Is the show condemning, or glorifying. I think it's closer to the latter, regardless of how poorly things went for Walter in the end.

> The whole point is that he's so brilliant that he can take over a whole regional drug trade in like a year. Well I'm sorry, but if he could do that, he could also have put his brilliance toward some other wildly successful business venture that would not have required blowing people up and putting his family in danger from like three different gangs of violent criminals.

Sure. But, again, I think this is just another implicit thesis of the show. It's easier and more fun to be an amoral asshole without regard for any of your obligations to anyone else.


Right, the show's position is that he took the "easier and more fun" way, because of his selfish pride, and ended up hurting everyone he cared about, which is why he's the villain. It's very clear about this!


I'm pretty sure this is one of those noisy minority things. But who knows, I'm not gonna do a scientific survey to figure it out :)


> Everyone hates Walter at the end.

Hate? Nah. He's tragic.

Does he do evil, despicable things? Absolutely. Are most of those things done because of jealousy, rage, or a failure to bother to understand the context in which he's operating? Definitely. But, like, unless you've never been jealous, blindingly angry, foolish, or far too hasty, you can see where (assuming turning yourself in to the cops isn't an option [0]) you might end up making similar choices. [1]

Is he prideful, wrathful, did he do many evil things? Yes, yes, and yes. It's not unreasonable to call his (in)actions -on balance- monstrous. But he's also relatable/understandable in a -er- "Greek tragedy" sort of way. He's a blunderer and a wrecker who probably deserved far worse than he got, but I find it dreadfully difficult to hate him when I consider the entire story.

[0] Which it pretty much immediately absolutely was not. Even at the start, all the money he made would have been forfeit and (because the USian "Drug War" is batshit crazy) prosecutors probably would have found a way to take the house and cars, leaving his family way worse off than if he'd done nothing at all.

[1] Having said that, there are so many points of decision that the odds that you'd walk his path exactly are approximately zero.


Hate at the end, yes. Tragic, also yes. There's no contradiction here!


Yeah, the conceit of Seinfeld was that the characters were crappy, but you liked them because they were funny. But they didn't actually lean into that as hard as, say, the finale would suggest. All of the characters have something sympathetic that you can like about them, even if you can buy the thesis that they are unsympathetic broadly.

The genius of IASIP is to just lean all the way into this trope. The characters are never sympathetic and never redeem themselves. It's almost an experiment in whether you can make people feel sympathetic toward awful (but entertaining) characters just through long familiarity with them. (Yes.)


Yeah this does seem right. Maybe as our own empire has been collapsing, our culture has been edging toward the brits'.


No, nationalism and patriotism started to be embarrassing to the educated classes in the US after the USSR collapsed. We had "won", and slavish obedience and loyalty are really not consistent with the values of liberalism and democracy, and empire is quite uncomfortable if you believe in human rights and self-determination, etc. Our society has been changing because it's running into the contradictions of a culture designed to foster the unity necessary to win wars and dominate the world and an idealism that says all humanity is equal and freedom and self-determination are inherently good.


I don't think "patriotism" and "slavish obedience and loyalty" are the same thing.


Can you articulate a meaningful distinction?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: