I'll always celebrate stories like this, but I also don't take some kind of anti-AWS lesson from it.
This company saved $800k/year. Perfect time to go in-house with this solution.
But when they were 1/10th this size, they'd only have saved $80k/year. Does that cover the cost of the engineering to build and maintain this system? Maybe not. And when they were 1/100th the size, it would have been laughable to go in-house.
At the right time, you make the right transitions.
Thank you for bringing up the engineering cost. People always look at this as just AWS > Bare metal or whatever, but there's so much more to it than that.
If they saved $800k per year, and they have to hire four additional ops engineers to run it at a cost of $400k per year, then they actually saved $400k. Which is still substantial and, all else being equal, sounds worthwhile.
If they saved $800k per year, and they have to hire ten additional ops engineers to run it at a cost of $1 million per year, then they've actually gone and burned $200k on something that provides no additional value to the business or their customers.
People don't consider productivity? Maybe things have gotten a lot better in the industry now. Otherwise, to rehash an older comment on HN:
I'd like to remind everyone about Uber's experience: no EC2-like functionality until at least 2018, probably even now. Teams would negotiate with CTO for more machines. Uber's container-based solution didn't support persistent volumes for years. Uber's distributed database was based on friendfeed's design and was notoriously harder to use than DynamoDB or Cassandra. Uber's engineers couldn't provision Cassandra instances via API. They had to fill in a 10-pager to justify their use cases. Uber's on-rack router broke back in 2017 and the networking team didn't know about it because their dashboard was not properly set up and what the funk is eBPF? Uber tried but failed to build anything even closer to S3. Uber's HDFS cluster was grossly inefficient and expensive. That is, Uber's productivity sucked because they didn't have the out-of-box flexibility offered by cloud.
The initial bit is important though. It creates a circular dependency. If you start out without AWS, your entire company's software from how you build monoliths/microservices/queues changes.
Look at Stack Overflow's architecture which stands apart because it was never designed to work in cloud from the beginning: https://stackexchange.com/performance
I'd argue that 90% of the SaaS doesn't have SO's scale. The whole thing would work just fine on a couple of FreeBSD servers running postgres and un-dockerized monolith. Half a rack at most with redundancy and replication.
But, if you've built your whole company around proprietary lamda functions and a vast range of AWS offerings, you're setting up yourself to never get out of the mess.
At what point do you have the time/money/confidence to invest goodness knows how much in a data centre with space to grow, to purchase an enormous amount of capital to have it all installed etc. the building alone could eat that first years saving easily.
How many people are now needed to fault-find bad hardware/software/networks, to be on call for any problems? How many calls out to the Electrician to fix some power issue?
How much to setup and run a large air-con system for the data centre. Maybe not much in the US where aircon is common but much more expensive in Europe.
The fact they could afford to do this over such a short time period speaks to having a decent amount of cash on-hand.
Anecdotal, but for one of my projects, Google Cloud / Compute Engine VMs cost around ~$5k a month all in. The exact same setup, when we moved it to LiquidWeb, cost us $2k.
Don't underestimate the savings that can be made from switching from a big-name cloud provider to a more old school hosting provider.
At work, people keep complaining about our costs and coming up with spreadsheets showing how much money we would save with our own hardware.
They never add the engineering costs. When they do, they forget to include the ongoing maintenance. Or the new SMEs that need to be hired (and on call). Or even the opportunity cost of doing a multi-year migration to arrive at the exact spot they already are today.
All that money, and noone is looking into optimizing our systems to shrink the bill...
80k ? Honestly probably does. Our ops team of 3 spends maybe 10% of the time on the managing of few hardware racks we have in our local colocation. There are even months where nothing at hardware/hypervisor level is touched
Yep, we should have pointed out that this has to be done in at the right time.
Generally this article was about how we saved $1M expense and we was able to share this saving with our customers.
Not an attack on AWS, I still use their platform for my other projects.
But to be accurate, this migration happened last year, and now we already doubled our usage and this brings us to $2M / year saving now.
I 100% agree with the comments below, use AWS while you are defining your product and growing, Todd (the founder) did this right.
Spending days and nights on managing your own infrastructure or paying a devops employee to do it, in the early phase is just pure waste, and takes away focus. But we moved away from AWS at the right time.
Also, yes we had to do this to be competitive, as prerendering is a resource heavy service, and if your site is like ProductBoard (awesome tool) which will not consume terabits of traffic or use petabytes of ram, then you can stay on AWS forever and enjoy the benefit of not caring.
And what we lost? Minor inconvenience at this point, I cannot just pull up a new database in 10 minutes, but we don't really do that anymore, most of our current projects requires months of research, planning, and delivery. With those time frames we can notify our devops and get everything in place way before we need it.
So, keep on using AWS (it rocks!), just be sure to pay attention to the bill, and don't underestimate the cost of the traffic.
> This company saved $800k/year. Perfect time to go in-house with this solution.
$800k/yr is like the cost of 2-3 engineers. Even if they're capable of doing all of the work that used to have been done by aws, you don't have any room to expand without having to put up high capital costs, and certainly not on a dime.
It sounds amazing now, but wait till the future comes and you can no longer run your own data center as cheaply as amazon.
this point is even more poignant when taking into account scalability and elasticity.
Our usage of Azure/O365/AWS saved us a lot of time staff and money during our make it or break it growth period. now we're a lot bigger and more stable we're having to reconsider allowing MS/Amazon bending us over the barrel quite so much.
Also your company needs to be mature enough to know really well what your hardware requirements are. For a growing company, it's really great to switch your RDS instance to a bigger type because your database load has tripled in a few months and you didn't know that was coming.
They don't mention at all what services they were using (other than slight mention of S3) which makes it very hard to respond to this. If you are running everything on EC2 then you are going to have a bad time (especially if you aren't using reserved instances).
AWS (IMHO) shines with the various services they provide (S3, Lambda, CloudFront, API Gateway, SQS< SES, to name a few). AWS is a game of trying to reduce your bill and often that means using AWS-specific services. If you want to stay completely "cloud agnostic" you are going to paying more than buying into a "cloud", in that scenario then you absolutely should be looking at dedicated servers. AWS is great because you can bring existing software and just run it in EC2 (or their container stuff if your software is containerized) but the AWS magic comes from using their managed services (also spinning up/down EC2 instances as needed, but if you are running them 24/7 then consider alternatives or at least pay for reserved).
Yeah, you need to do calculation of what you are doing right now vs AWS.
If you already have a mature team that is doing well optimising the environment, you have stable demand and no need to develop things rapidly then it is very likely that going cloud is poor choice.
As to "cloud agnostic", don't believe this bullshit. In my opinion most projects fare much better by just letting go of this "cloud agnostic" and just getting tied and locked in to the vendor. It is not like there is a good chance Amazon (or Microsoft or Google for that matter) will suddenly pull a significant price hike or another move out of step with other vendors.
Spending effort on trying to make your app "cloud agnostic" usually ends up with far higher development costs and a chance of failure for no benefit. Embracing one vendor in this case is usually best way to achieve smaller, leaner app that is using the platform well.
It is the same story as with SQL. Trying to use frameworks to keep your app DBMS-agnostic but then nobody ever migrates their apps to another DBMS. And for various good reasons: you hired your staff for their expertise with X, they are used to it, so now going for Y will usually be far higher cost than the benefits.
And likely a company who does not use cloud resorts to Chef/Puppet/TFE and what not to manage their machines. Such scripting tools may work for a small team as the engineers deal with their specific needs day in and day out, but it is expensive to scale out to larger teams. I'd assume only a few engineers would enjoy writing hundreds if not thousands of lines of yaml or the whatever so-called DSLs offered by the aforementioned tools. Plus, it takes effort to implement autoscaling, metadata management, image-building process like AMI, security groups or something similar, availability zones, and etc.
This is likely only true until they have enough lock-in on those cloud products to really turn the screws and extract maximum profits from people that are TOTALLY screwed by being completely locked into proprietary AWS services...
This is basically the natural progression of SaaS...
Yes. If you use and manage AWS resources as you would your own on-prem resources then you're not going to have a good time. As soon as you think you need EC2 instances you need to re-think your architecture. You're probably not using AWS most effectively.
Going from Alooma (pre-Google acquire) to DMS saved us thousands. I was shocked when I read that the only thing that DMS cost was running a small EC2 instance. It's a fairly good service - it mostly just runs. AWS has so many offerings like that. They really want to make sure you stick with their ecosystem, and it pays to do so.
I'm so amazed that somehow people completely forget that for literally decades, web host provided dedicated hosting options at fantastic prices.
Yes, loooong time ago - to get your dedicated server might have taken a few hours to provision and the instant server access that AWS brought should not be discredited.
But large numbers of web host today allow you to programmatically spin up a dedicated web host instantaneously and at a fraction of the cost.
> Yes, loooong time ago - to get your dedicated server might have taken a few hours to provision and the instant server access that AWS brought should not be discredited.
At one point it took often days for a dedicated server to be set up. We also didn't have such nice provisioning tools.
Now it just seems like cargo cult to use cloud providers as the only option. People just completely discount dedicated servers.
The one big thing missing from dedicated hosts is an S3 equivalent. Sure, you can get a huge hard drive for cheap but this will not have the durability requirements for storing your precious data.
And if you try to use AWS just for S3 then you will pay a lot extra for the bandwidth charges of bringing the data from S3 to your server (something that is free if you were to use EC2 or other AWS services).
Not to mention having your own datacenter, which is even cheaper (unless you do something stupid).
EDIT: to the naysayers: I worked in various companies (from tiny to huge) maintaining their own DCs and had access to financial data. And I was involved in the setting up new DCs.
Hosting providers are a pain. My server was down for full day because the provider was being DDoSed. AWS has DDoS protection by default. If I was on AWS, my server would not go down due to network DDoS attacks. That is just one of many things AWS does for you that many hosting providers don't.
This is the Trillion Dollar Paradox described by Martin Casado. You’re crazy if you don’t start your business in the cloud, you’re crazy if you stay there.
My new startup is focused on helping application owners repatriate their workloads into their own infrastructure.
Our goal is to solve the network complexity challenges with a fully open network stack (open source software with all of the hardware options you would expect, and some you wouldn’t). The solution is designed to be turnkey and require very little network experience. It will use standard DevOps tools that you’re already using.
We’re announcing it in two weeks and will be posting info here on HN!
Damn that's really interesting thanks for sharing. Do you have like an authorative link on this paradox?
I've been getting by on like 80$/month hetzner servers (Like ancient 10 year old pizza box machines) for my businesses for a long while. Never did the cloud thing, I can run like three or four websites on one of those bad boys. I guess stuff like AWS makes sense if your computational workload happens in bursts or whatever? But 80$/month overhead costs are like nothing, I spend more than that on a good night out level.
> This is the Trillion Dollar Paradox described by Martin Casado. You’re crazy if you don’t start your business in the cloud, you’re crazy if you stay there.
That's not a paradox. You're not crazy in either case.
Starting in the cloud reduces costs for some strategies by removing necessary engineering. Starting in the cloud increases costs for other strategies by charging too much for commodity offerings.
It's relatively straightforward to make the choice as soon as you put a specific business in the crosshairs.
I'm glad to see more of these types of articles, but at the same time I'm a bit flabbergasted that this isn't obvious for so many people.
These cloud providers are, by definition, charging you more than it would cost you to run it yourself. What you get in return is a guarantee of expertise and an ecosystem.
- may spend $250K on servers, replaced after 3 years becomes $83k/yr
- may spend $120-250K on extra staff to maintain the infrastructure
- may spend $15K for a cage in a DC
They still save $452K/yr overall (actual savings 1st year only $285K). It's still a savings for sure, but always keep TCO in mind.
The real fun comes later when you outgrow your cage and there's not enough space left in that DC, or they just have shitty service constantly knocking out your racks, and you have to consider splitting your infra between DCs (a huge rewrite) or moving DCs (a huge literal lift and shift). Have been part of both, it's... definitely a learning experience.
I've said this a hundred times and it seems not loud enough.
AWS is not cheap because of your server costs.
AWS is cheap because of elasticity, velocity (opportunity cost of next feature), and reduced maintenance hours.
"The cloud" was never (afaik) was about getting a cheaper VPS. It was about being able to get them on demand, give them back on demand, and generally not have to maintain anything besides your code (and maybe apply updates to datastores / AMIs)
Now, if those premises are not true for your startup/business, then AWS is not the tool for you. I didnt see any analysis of ongoing maintenance costs in the 800k saved, but will it take 1-2 FTE engineers to now be more oncall, more server upgrades, more security patches etc? That's easily 1/2 that savings gone already.
Edit: for the most part these attributes apply to GCP, Azure, Heroku etc as well, its not just about AWS
So the team is now responsible for backups, hardware ordering,.forecast etc?
How big is the team now compared to before?
Does it scale?
If you price it correctly and keep the free tier small, I would either talked to AWS for better pricing or moved to another cloud Provider.
S3 on AWS is a total no-brainer, minio on bare metal might mean much more work and a bigger infra team than business actually wants.
I would also love to know what optimizations are already in place. Does cloudflare caching work? Are the results compressed on rest? Is geolocation latency relevant?
Why even Cassandra? Are websites not unique? Wouldn't a nginx and a few big servers not work?
But who knows? The article doesn't tell me that :-(
There is no way this figure is accurate. The annual spend cited of $1,000,000 is purely hypothetical, as admitted here:
"However, all this data and processes need to happen on a server and, of course, we used AWS for it. A few years of growth later, we’re handling over 70,000 pages per minute, storing around 560 million pages, and paying well over $1,000,000 per year.
Or at least we would be paying that much if we stayed with AWS. Instead, we were able to cut costs by 80% in a little over three months with some out-of-the-box thinking and a clear plan."
There is not quite enough information here to be sure, but this article highlights transmission costs. This particular business model involves throwing around big chunks of data just in case they end up being needed and then handing them back out in response to potentially large numbers of requests. That would make this particular usage pattern fit to exactly what AWS is charging the most for. Also many alternative AWS services that can be used to speed up or simplify services are not really going to help with this case.
So an alternative way of interpreting this is more along the lines of: We may have saved up to 80% of server costs by moving from AWS, but you almost certainly won't save that much even if a bunch gets spent on developing operations and tools.
I feel like there's a middle step missing from this article (or I just missed it reading quickly) - did they build their own data center? Where are these new non-AWS servers physically located?
In general, last time I looked at AWS it made sense from 2TB to 30TB a month, and under 400k connections a day. If either range was exceeded, than the service ceased to be the economical choice when compared with CDN providers, and colo/self-managed unlimited-traffic options.
For example, if you primarily serve large media or many tiny files to clients that don't support http Multipart Types, than AWS can cost a lot more than the alternatives. However, AWS is generally an economical cloud provider, and a good option for those who outsourced most of their IT infrastructure.
The article would be better if it cited where the variable costs arose.
I believe this is the use case Cloudflare is really targeting with R2. They recently connected Cache Reserve to R2 to make this even easier. We wrote up a breakdown for S3 vs R2 and found that R2 would be significantly cheaper when the majority of traffic is cached data, https://www.vantage.sh/blog/cloudflare-r2-aws-s3-comparison
I find this interesting, if nothing else. My first question is what was the opportunity cost of focusing manpower to setting up on-prem infrastructure that now needs maintained? What on the product roadmap was sacrificed/delayed in exchange for the time on this project? What are the projected future hiring costs to maintain these servers (and applications like Cassandra!) going forward? Nothing is free, and at just 4-5 additional hires they will be giving back a large chunk of that $800k to employees. IDK - maybe that's a fare trade-off to pump up the common man with money instead of the establishment.
I found the headline to be misleading. The article is mostly about the migration process (which is interesting), but very little about the details of the cost savings.
What does it cost to run their data center? What are the salaries they are paying for internal IT efforts to administer it? Is it an apples-to-apples comparison, e.g. are they load balancing across multiple datacenters in case of an outage?
It sounds like this was a good move for Prerender but it's hard to generalize the cost claims to other situations without details.
I expect to see a great deal more of the "cheap and cheerful" AWS migration stories in the future. With the tanking of the market and (apparent) limits to growth being in the forefront, reducing expenses will become more important.
Before, it was easy to justify almost any expense with the "we just need to get 1% of this $100 billion market" and now it is "hunker down and do everything you can to be ramen-profitable, in order to survive and thrive".
When the cost of delivering your product/service is mostly compute or traffic, sure, migrating off of AWS is a must once you reach a certain scale.
But for the other 99% [0], where infrastructure is but a small cost, then think really hard if you're willing to trade the engineering effort for the convenience of managed cloud services.
[0]: or 90%, or 80% or who cares, but a majority of software services seem to NOT be compute- or traffic- heavy.
[+] [-] mabbo|3 years ago|reply
This company saved $800k/year. Perfect time to go in-house with this solution.
But when they were 1/10th this size, they'd only have saved $80k/year. Does that cover the cost of the engineering to build and maintain this system? Maybe not. And when they were 1/100th the size, it would have been laughable to go in-house.
At the right time, you make the right transitions.
[+] [-] MajimasEyepatch|3 years ago|reply
If they saved $800k per year, and they have to hire four additional ops engineers to run it at a cost of $400k per year, then they actually saved $400k. Which is still substantial and, all else being equal, sounds worthwhile.
If they saved $800k per year, and they have to hire ten additional ops engineers to run it at a cost of $1 million per year, then they've actually gone and burned $200k on something that provides no additional value to the business or their customers.
[+] [-] hintymad|3 years ago|reply
I'd like to remind everyone about Uber's experience: no EC2-like functionality until at least 2018, probably even now. Teams would negotiate with CTO for more machines. Uber's container-based solution didn't support persistent volumes for years. Uber's distributed database was based on friendfeed's design and was notoriously harder to use than DynamoDB or Cassandra. Uber's engineers couldn't provision Cassandra instances via API. They had to fill in a 10-pager to justify their use cases. Uber's on-rack router broke back in 2017 and the networking team didn't know about it because their dashboard was not properly set up and what the funk is eBPF? Uber tried but failed to build anything even closer to S3. Uber's HDFS cluster was grossly inefficient and expensive. That is, Uber's productivity sucked because they didn't have the out-of-box flexibility offered by cloud.
[+] [-] systemvoltage|3 years ago|reply
Look at Stack Overflow's architecture which stands apart because it was never designed to work in cloud from the beginning: https://stackexchange.com/performance
I'd argue that 90% of the SaaS doesn't have SO's scale. The whole thing would work just fine on a couple of FreeBSD servers running postgres and un-dockerized monolith. Half a rack at most with redundancy and replication.
But, if you've built your whole company around proprietary lamda functions and a vast range of AWS offerings, you're setting up yourself to never get out of the mess.
[+] [-] lbriner|3 years ago|reply
At what point do you have the time/money/confidence to invest goodness knows how much in a data centre with space to grow, to purchase an enormous amount of capital to have it all installed etc. the building alone could eat that first years saving easily.
How many people are now needed to fault-find bad hardware/software/networks, to be on call for any problems? How many calls out to the Electrician to fix some power issue?
How much to setup and run a large air-con system for the data centre. Maybe not much in the US where aircon is common but much more expensive in Europe.
The fact they could afford to do this over such a short time period speaks to having a decent amount of cash on-hand.
[+] [-] i_have_an_idea|3 years ago|reply
Don't underestimate the savings that can be made from switching from a big-name cloud provider to a more old school hosting provider.
[+] [-] outworlder|3 years ago|reply
At work, people keep complaining about our costs and coming up with spreadsheets showing how much money we would save with our own hardware.
They never add the engineering costs. When they do, they forget to include the ongoing maintenance. Or the new SMEs that need to be hired (and on call). Or even the opportunity cost of doing a multi-year migration to arrive at the exact spot they already are today.
All that money, and noone is looking into optimizing our systems to shrink the bill...
[+] [-] xani_|3 years ago|reply
[+] [-] hisorange|3 years ago|reply
Yep, we should have pointed out that this has to be done in at the right time. Generally this article was about how we saved $1M expense and we was able to share this saving with our customers. Not an attack on AWS, I still use their platform for my other projects.
But to be accurate, this migration happened last year, and now we already doubled our usage and this brings us to $2M / year saving now.
I 100% agree with the comments below, use AWS while you are defining your product and growing, Todd (the founder) did this right. Spending days and nights on managing your own infrastructure or paying a devops employee to do it, in the early phase is just pure waste, and takes away focus. But we moved away from AWS at the right time.
Also, yes we had to do this to be competitive, as prerendering is a resource heavy service, and if your site is like ProductBoard (awesome tool) which will not consume terabits of traffic or use petabytes of ram, then you can stay on AWS forever and enjoy the benefit of not caring.
And what we lost? Minor inconvenience at this point, I cannot just pull up a new database in 10 minutes, but we don't really do that anymore, most of our current projects requires months of research, planning, and delivery. With those time frames we can notify our devops and get everything in place way before we need it.
So, keep on using AWS (it rocks!), just be sure to pay attention to the bill, and don't underestimate the cost of the traffic.
Have a nice one
[+] [-] chii|3 years ago|reply
$800k/yr is like the cost of 2-3 engineers. Even if they're capable of doing all of the work that used to have been done by aws, you don't have any room to expand without having to put up high capital costs, and certainly not on a dime.
It sounds amazing now, but wait till the future comes and you can no longer run your own data center as cheaply as amazon.
[+] [-] senectus1|3 years ago|reply
[+] [-] vlunkr|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] joshstrange|3 years ago|reply
AWS (IMHO) shines with the various services they provide (S3, Lambda, CloudFront, API Gateway, SQS< SES, to name a few). AWS is a game of trying to reduce your bill and often that means using AWS-specific services. If you want to stay completely "cloud agnostic" you are going to paying more than buying into a "cloud", in that scenario then you absolutely should be looking at dedicated servers. AWS is great because you can bring existing software and just run it in EC2 (or their container stuff if your software is containerized) but the AWS magic comes from using their managed services (also spinning up/down EC2 instances as needed, but if you are running them 24/7 then consider alternatives or at least pay for reserved).
[+] [-] twawaaay|3 years ago|reply
If you already have a mature team that is doing well optimising the environment, you have stable demand and no need to develop things rapidly then it is very likely that going cloud is poor choice.
As to "cloud agnostic", don't believe this bullshit. In my opinion most projects fare much better by just letting go of this "cloud agnostic" and just getting tied and locked in to the vendor. It is not like there is a good chance Amazon (or Microsoft or Google for that matter) will suddenly pull a significant price hike or another move out of step with other vendors.
Spending effort on trying to make your app "cloud agnostic" usually ends up with far higher development costs and a chance of failure for no benefit. Embracing one vendor in this case is usually best way to achieve smaller, leaner app that is using the platform well.
It is the same story as with SQL. Trying to use frameworks to keep your app DBMS-agnostic but then nobody ever migrates their apps to another DBMS. And for various good reasons: you hired your staff for their expertise with X, they are used to it, so now going for Y will usually be far higher cost than the benefits.
[+] [-] hintymad|3 years ago|reply
[+] [-] onlyrealcuzzo|3 years ago|reply
This is basically the natural progression of SaaS...
[+] [-] datalopers|3 years ago|reply
[+] [-] taylodl|3 years ago|reply
[+] [-] dinobones|3 years ago|reply
They are awful to develop against, awful to test against, and often times "just work" until they don't.
[+] [-] shepardrtc|3 years ago|reply
[+] [-] bachmeier|3 years ago|reply
It's possible that they are not interested in a response. They are saying what worked for them, whether or not others want to agree.
[+] [-] outcoldman|3 years ago|reply
[+] [-] GoblinSlayer|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] alberth|3 years ago|reply
I'm so amazed that somehow people completely forget that for literally decades, web host provided dedicated hosting options at fantastic prices.
Yes, loooong time ago - to get your dedicated server might have taken a few hours to provision and the instant server access that AWS brought should not be discredited.
But large numbers of web host today allow you to programmatically spin up a dedicated web host instantaneously and at a fraction of the cost.
[+] [-] that_guy_iain|3 years ago|reply
At one point it took often days for a dedicated server to be set up. We also didn't have such nice provisioning tools.
Now it just seems like cargo cult to use cloud providers as the only option. People just completely discount dedicated servers.
[+] [-] throwaway858|3 years ago|reply
And if you try to use AWS just for S3 then you will pay a lot extra for the bandwidth charges of bringing the data from S3 to your server (something that is free if you were to use EC2 or other AWS services).
[+] [-] goodpoint|3 years ago|reply
EDIT: to the naysayers: I worked in various companies (from tiny to huge) maintaining their own DCs and had access to financial data. And I was involved in the setting up new DCs.
[+] [-] kaptainscarlet|3 years ago|reply
[+] [-] floatinglotus|3 years ago|reply
My new startup is focused on helping application owners repatriate their workloads into their own infrastructure.
Our goal is to solve the network complexity challenges with a fully open network stack (open source software with all of the hardware options you would expect, and some you wouldn’t). The solution is designed to be turnkey and require very little network experience. It will use standard DevOps tools that you’re already using.
We’re announcing it in two weeks and will be posting info here on HN!
[+] [-] jamal-kumar|3 years ago|reply
I've been getting by on like 80$/month hetzner servers (Like ancient 10 year old pizza box machines) for my businesses for a long while. Never did the cloud thing, I can run like three or four websites on one of those bad boys. I guess stuff like AWS makes sense if your computational workload happens in bursts or whatever? But 80$/month overhead costs are like nothing, I spend more than that on a good night out level.
[+] [-] JohnHaugeland|3 years ago|reply
That's not a paradox. You're not crazy in either case.
Starting in the cloud reduces costs for some strategies by removing necessary engineering. Starting in the cloud increases costs for other strategies by charging too much for commodity offerings.
It's relatively straightforward to make the choice as soon as you put a specific business in the crosshairs.
Edit: why is this downvoted?
[+] [-] P5fRxh5kUvp2th|3 years ago|reply
These cloud providers are, by definition, charging you more than it would cost you to run it yourself. What you get in return is a guarantee of expertise and an ecosystem.
[+] [-] 0xbadcafebee|3 years ago|reply
The real fun comes later when you outgrow your cage and there's not enough space left in that DC, or they just have shitty service constantly knocking out your racks, and you have to consider splitting your infra between DCs (a huge rewrite) or moving DCs (a huge literal lift and shift). Have been part of both, it's... definitely a learning experience.
[+] [-] maerF0x0|3 years ago|reply
AWS is not cheap because of your server costs.
AWS is cheap because of elasticity, velocity (opportunity cost of next feature), and reduced maintenance hours.
"The cloud" was never (afaik) was about getting a cheaper VPS. It was about being able to get them on demand, give them back on demand, and generally not have to maintain anything besides your code (and maybe apply updates to datastores / AMIs)
Now, if those premises are not true for your startup/business, then AWS is not the tool for you. I didnt see any analysis of ongoing maintenance costs in the 800k saved, but will it take 1-2 FTE engineers to now be more oncall, more server upgrades, more security patches etc? That's easily 1/2 that savings gone already.
Edit: for the most part these attributes apply to GCP, Azure, Heroku etc as well, its not just about AWS
[+] [-] Gregioei|3 years ago|reply
So the team is now responsible for backups, hardware ordering,.forecast etc?
How big is the team now compared to before?
Does it scale?
If you price it correctly and keep the free tier small, I would either talked to AWS for better pricing or moved to another cloud Provider.
S3 on AWS is a total no-brainer, minio on bare metal might mean much more work and a bigger infra team than business actually wants.
I would also love to know what optimizations are already in place. Does cloudflare caching work? Are the results compressed on rest? Is geolocation latency relevant?
Why even Cassandra? Are websites not unique? Wouldn't a nginx and a few big servers not work?
But who knows? The article doesn't tell me that :-(
[+] [-] hazmazlaz|3 years ago|reply
"However, all this data and processes need to happen on a server and, of course, we used AWS for it. A few years of growth later, we’re handling over 70,000 pages per minute, storing around 560 million pages, and paying well over $1,000,000 per year.
Or at least we would be paying that much if we stayed with AWS. Instead, we were able to cut costs by 80% in a little over three months with some out-of-the-box thinking and a clear plan."
[+] [-] m0llusk|3 years ago|reply
So an alternative way of interpreting this is more along the lines of: We may have saved up to 80% of server costs by moving from AWS, but you almost certainly won't save that much even if a bunch gets spent on developing operations and tools.
[+] [-] maxfurman|3 years ago|reply
[+] [-] Joel_Mckay|3 years ago|reply
For example, if you primarily serve large media or many tiny files to clients that don't support http Multipart Types, than AWS can cost a lot more than the alternatives. However, AWS is generally an economical cloud provider, and a good option for those who outsourced most of their IT infrastructure.
The article would be better if it cited where the variable costs arose.
[+] [-] TheGuyWhoCodes|3 years ago|reply
Regardless, starting a new Cassandra cluster in late 2022?! I bet they can save even more by just going with scylladb
[+] [-] epberry|3 years ago|reply
[+] [-] gibsonf1|3 years ago|reply
[+] [-] hnrodey|3 years ago|reply
[+] [-] wglass|3 years ago|reply
What does it cost to run their data center? What are the salaries they are paying for internal IT efforts to administer it? Is it an apples-to-apples comparison, e.g. are they load balancing across multiple datacenters in case of an outage?
It sounds like this was a good move for Prerender but it's hard to generalize the cost claims to other situations without details.
[+] [-] theptip|3 years ago|reply
This seems like a key detail when telling people about your migration off AWS.
[+] [-] shrubble|3 years ago|reply
Before, it was easy to justify almost any expense with the "we just need to get 1% of this $100 billion market" and now it is "hunker down and do everything you can to be ramen-profitable, in order to survive and thrive".
[+] [-] taldo|3 years ago|reply
[0]: or 90%, or 80% or who cares, but a majority of software services seem to NOT be compute- or traffic- heavy.