what do you think about it?
https://www.youtube.com/watch?v=G8Bt3jEhIwA
Ask HN: Is your company sticking to on-premise servers? Why?
701–710 of 782 posts
Re: Ask HN: Is your company sticking to on-premise servers? Why?
#702Earlier quoted context omitted.
Does it actually save or does it just encourage waste by the developers and poor system design? I’ve heard stories of companies having each PR spin up something like 20 ec2 instances to build up a whole deployment. A CICD design like that used to be a fireable offense. Now people see that and assume it’s saving them money because it would have bottlenecked before.
That’s a pretty extreme example of CI infrastructure, but okay... so what? 20 t2 mediums costs under a dollar an hour at list rates, and if you’re using a lot of AWS infrastructure can cost a lot less. How much is the confidence that that PR will not break master worth to you? How many hours of engineer code review time would it take to achieve that same level of confidence in your build that spinning up 20 ec2 insta…
> How much is the confidence that that PR will not break master worth to you?
That’s exactly the mental trap I’m talking about. Requiring 20 instances to try to mirror production instead of getting better testing in place is a sign of testing immaturity.
I have significantly less confidence in the products that use this testing strategy because it really means they don’t have much in place for testing infrastructure to stub things out, inject failures, etc.
And it’s not t2 mediums. It’s whatever is specced for production because we’re such good engineers that we want to test in a production like env, right?
> Before you assume that it’s wasteful for any organization to throw cloud at a problem, realize there are many orgs for which a few hundred dollars of cloud compute spend per production release
That’s not even close. It’s hundreds of dollars a day leading up to thousands per release with larger teams.
Re: Ask HN: Is your company sticking to on-premise servers? Why?
#703Earlier quoted context omitted.
Does it actually save or does it just encourage waste by the developers and poor system design? I’ve heard stories of companies having each PR spin up something like 20 ec2 instances to build up a whole deployment. A CICD design like that used to be a fireable offense. Now people see that and assume it’s saving them money because it would have bottlenecked before.
So I've setup processes like you described where every PR would spin up 20 ec2 instances, run a huge number of parallel testing, and then shut itself down. The savings associated with developers getting feedback on a full regression test of the system in 20 minutes vs. 400 minutes was significant.
That’s parallelizing, which is not what I’m talking about. I’m talking about pointlessly building up huge environments that “match production”.
Re: Ask HN: Is your company sticking to on-premise servers? Why?
#704Earlier quoted context omitted.
What about first-party SaaS? Those can also be big features that bring people to some cloud providers. Not all SaaS requires you to trust your data/availability to some random vendor. Of course those first-party SaaS aren't typically suitable for lift-and-shift by their very nature, and they can still have some rough edges, but IMO you can expect them to be almost as reliable as IaaS
First-party SaaS meaning things like RDS, DBaaS, queues, LBs etc? Most of that I would sort of put into a IaaS controlled PaaS, rather than true IaaS SaaS. Yes, these are generally higher on the trust spectrum as they don't involve additional vendors accessing/managing/storing data.
A major one I'm thinking of is BigQuery, also of course all the various db/queue solutions outside of your typical S3 clone as you mentioned. That would make sense viewing them as platforms though
Re: Ask HN: Is your company sticking to on-premise servers? Why?
#705Earlier quoted context omitted.
The rack is $2800 per month, not $1400. The lowest advertised pricing does not include enough power to supply half of what's in the rack. Add $200 per server per month to have a gigabit uplink. Add $4000 per server per lifetime for VmWare licenses. These are reasonable estimates of course. Could be multiple of that depending on what hardware is used and what colo. Physical hardware easily gets as expensive as any clo…
Not easily; you’re making the argument that there can be high expenses for collocating but you’re talking about a -lot- of computational power. I know that hardware varies a lot for sure, but for context I put together 3 racks 50% density with an 800gbit backplane for around 18k eur/mo. I spared no expense, official juniper QSFPs (which are egregiously overpriced) and top of the line Dell servers with full out of ban…
Physical infrastructure is always overprovisioned because it has to be planned long in advance and the smallest unit is huge (8 cores? 128 GB of RAM? for a small server).
If anything that's an argument against physical infra, not in favor of. Although it's fine if one wants a lot of the same big servers (an Hadoop cluster, or video computing cluster, or a CDN), which are the few use cases where physical can make sense (and hybrid cloud probably makes even more sense).
With AWS, you'd never spin half of that infra upfront. You'd spin a few VMs and start running stuff. If the project goes well, spin more or bigger VMs, otherwise spin down. Cost is very dynamic and the company doesn't have to spend half a million upfront, which is a big financial problem for many companies.
Anyway. We can both agree on AWS being overpriced. The reference on costs should be Google Cloud if one is cost conscious, not AWS. Google Cloud is often half the costs of AWS for the same thing.
AWS vs Google comparison, bit old and instance types have changed but relative pricing has not moved https://thehftguy.com/2018/11/13/2018-cloud-pricing-aws-now-...
And this one more recent since they've released high memory instances to compete with SoftLayer: https://thehftguy.com/2018/11/13/2018-cloud-pricing-aws-now-...
Re: Ask HN: Is your company sticking to on-premise servers? Why?
#706Well, for one thing: jobs. It takes a lot of IT man-power to manage an on-premise solution, especially when you run everything on-premise. Just imagine if the CTO were to switch the company to a cloud based solutions, it would save the company millions of dollars but also it would mean cutting a lot of jobs. Gov departments that use on-premise do so for security reasons and to maintain existing jobs.
Re: Ask HN: Is your company sticking to on-premise servers? Why?
#707Earlier quoted context omitted.
Not easily; you’re making the argument that there can be high expenses for collocating but you’re talking about a -lot- of computational power. I know that hardware varies a lot for sure, but for context I put together 3 racks 50% density with an 800gbit backplane for around 18k eur/mo. I spared no expense, official juniper QSFPs (which are egregiously overpriced) and top of the line Dell servers with full out of ban…
Physical infrastructure is always overprovisioned because it has to be planned long in advance and the smallest unit is huge (8 cores? 128 GB of RAM? for a small server). If anything that's an argument against physical infra, not in favor of. Although it's fine if one wants a lot of the same big servers (an Hadoop cluster, or video computing cluster, or a CDN), which are the few use cases where physical can make sens…
My costings are based on GCP; with sublime discounts even.
And, I would really agree with you if not for 2 things:
1) "wasted" cycles are not wasted, the CPU will clock down.
2) Kubernetes was designed specifically for this, the idea is you slice the CPU up so much that you dont waste much resources.
It's astonishingly capable of consuming all resources.
By the by; RAM is never "wasted", it's used for various caches.
Re: Ask HN: Is your company sticking to on-premise servers? Why?
#708Earlier quoted context omitted.
A few years ago I was trying to start a company and get it off the ground. We had to make decisions on our tech stack and whether we were going to use AWS and build around their infra. Our business was very data heavy and required transferring large datasets from outside to our databases. Even in our early prototypes, we realized that we couldn’t scale cost-effectively on AWS. I figured out that we could colocate and…
> I remember saying to my cofounder why does anyone use AWS, you can do this on your own way cheaper. I agree with everything you say - I'm convinced that a huge part of the cloud's financial success is due to how it allows CTOs/CIOs to indulge their fantasies about having a mega-scalable app - even if their workloads are very regular and predictable. Along the lines of buying an expensive sports car but never drivin…
From a developer perspective, I prefer to work with cloud providers because I can do more with fewer developers because I'm not dealing with sysadmins too. I can throw up a EMR cluster with minimal effort and get a working product out the door quickly.
These things don't matter for large, established companies because they already have DevOps, SysAdmin, and Development teams. But for smaller dev shops, it absolutely makes a difference when you can generate a good bit more efficiency from your development staff.
Re: Ask HN: Is your company sticking to on-premise servers? Why?
#709Earlier quoted context omitted.
I know currently our problem is finding proper staff and that is why we are considering moving to a cloud provider. Especially for database hosting, using a database as a service becomes very attractive from a staffing perspective just because we can't seem to find good candidates and we've been training younger people into being DBAs but they ultimately want to do something else after a while.
RDS and the like still need about the same amount of DBA'ing, no?
No.
Re: Ask HN: Is your company sticking to on-premise servers? Why?
#710Earlier quoted context omitted.
Infiniband and friends aren't cpu interconnects, they're alternatives to ethernet. Network latency is important and it's not that hard to write code whose performance is bounded by io latency/throughput.
> it's not that hard to write code whose performance is bounded by io latency/throughput I suspect that most people don't, though. How many applications are built in Ruby, Python, or PHP, using some very productive but inefficient framework? Those are all very fine tools in their own way, and are the right tool for the job in many contexts. But they're unlikely to saturate IO.
[deleted]