11 ms·
> "Starting a web-based or SaaS (Software as a Service) business was virtually unheard of before the age of IaaS" Nonsense. There were plenty of SaaS startups.
by manigandham 5y ago
> "Starting a web-based or SaaS (Software as a Service) business was virtually unheard of before the age of IaaS"
Nonsense. There were plenty of SaaS startups. There was even a little event called the dotcom boom all about internet companies. This lack of history and experience is why new companies get into this cloud-first mess in the first place.
Cloud is primarily for flexibility in iteration, dynamic scaling, or complex configurations that would be otherwise hard to do. If you have steady-state load like this then a few servers in your colo is pretty simple and far cheaper.
Companies also vastly overestimate their scale when their entire business could probably fit on a single commodity server.
- xuki 5y agoI'd say don't even consider colo unless you have a specific use case. Rented dedicated servers are cheap, let someone else take care of the hardware.
- manigandham 5y agoTrue, there's a wide spectrum in the middle from rented colo to managed servers.
- bsenftner 5y agoYes, they are cheap. Running one's own server is also easy peasy; far too many think it is difficult, it is not. The most expensive part is the electricity.
- maccard 5y ago> The most expensive part is the electricity. No, the most expensive part is the persons time for managing it. I can rent a monstrous Dedicated Server for $400/month from OVH, but even with a UK salary, if I have to spend more than 1 day a month on it in any shape or form (and that includes the initial setup), it's cheaper to use "the cloud" or some form of a managed service.
- vidarh 5y agoIf you have to use more than one a day a month managing the server, you are doing something wrong. I used to manage multiple racks worth of servers on top of managing the 1k containers running on them, maintaining the (pre-kubernetes) orchestration software I had written to deploy containers to our servers, and still had time left over to spend the majority of my time on the architecture and project management of new projects for clients.
- treis 5y agoI'd say if you're not spending one day a month you're doing something wrong. Namely, you're not testing your back ups and disaster recovery often enough.
- brimble 5y agoYou're right, but given the context of the thread, it's worth pointing out that's not extra work that one doesn't also need to do with cloud hosting. Ought to test your backups and disaster recovery regularly, either way.
- vidarh 5y agoThat's not managing the server. That's managing your application setup and not something that takes additional time for managed servers over cloud setups, because you still need all of those things for a cloud setup. It also should not take anywhere near a day per server per month - if it does, then in a disaster scenario it means you're unable to recover at a reasonable pace.
- treis 5y ago>That's not managing the server. That's managing your application setup and not something that takes additional time for managed servers over cloud setups, because you still need all of those things for a cloud setup. It is additional time because the cloud handles the whole class of "your hardware died" problems.
- koolba 5y ago> The most expensive part is the electricity. There’s more than a kWh rate for that though. There’s battery backup power, diesel backup, and failover hot switching. It’s not like just plugging in your phone to charge.
- m348e912 5y agoEasy or not, it's a job. Configuring, patching, upgrading, troubleshooting, securing, monitoring. It's only not expensive if your time is worth nothing.
- ykevinator2 5y ago
- greedo 5y agoAnd you still need to do this with an ec2 instance. Sure you can automate a lot of it via config mgmt/orchestration, but unless you're using serverless stuff on AWS, it's an awful lot like having your own VMs.
- stephbu 5y agoIt’s pretty hard to generalize this without qualifiers. Electricity can be the most expensive problem, but it requires carefully planned control of the other factors - e.g large scale with highly automated servers, network, and meat-reducing control planes to become true. Otherwise factors such as people and under-utilization can especially dominate smaller and/or less efficient facilities. Thinking thru the factors, many seem obvious, but are often forgotten/ignored when comparing rental or IaaS costs.: Space is a fixed cost driven by market rates and maximum Server Capital Costs i.e. floor space. Failing to fill the room increases your cost/server efficiency. Pretty common to run out of thermal/power before you run out space, as equipment efficiency increases through the lifespan of the facility. Server and Power costs scale together, carry a minimum cost for keeping machines on, and vary based on utilization. Again if the servers aren’t doing work, your efficiency ratio will drop. Larger space typically have pre negotiated power commitments too - failing to consume that carries fiscal penalties. Servers unit costs are fairly cheap, storage not so much. Full utilization throughout capital/lease lifespan is the goal - anything less increases relative cost/server. Network costs scale with Server Costs, and vary again by utilization - minimum invest rules apply, all servers need at least one network port, as well as upstream Core/TOR/Miniswitch gear. The network gear lifespan is typically longer than servers, but shorter than facilities. It usually incurs annual support/maintenance charges too. Bandwidth charges are variable as expected. People costs scale with a step-function and numbers driven by minimum coverage requirements, task complexities, and level of human toil. Performing any task on a device by-hand is expensive in most markets - touches on tickets, change management, task time etc. Fully burdened S+R in Western cultures is typically ~2x the salary - a $80K employee probably costs around $150K by the time all the workplace costs, taxes, and benefits are paid. Network folk are typically premium resources compared to DC Ops. Sustainable 24x7 coverage looks like a staff of 3-4 people.
- vidarh 5y agoThe thing is, you can buy your way out of most of these considerations by either renting colo space or renting managed servers until/unless you're at a scale where there are savings to doing it yourself. This is a commodity service with margins a tiny fraction of AWS' margins. Buying services at those levels instead of doing hosting on prem still nets you 80%-90% of the savings vs. cloud. Sometimes it nets you greater savings because it makes it easier to move your workloads to cheaper locations (e.g. for a small company in London operating servers somewhere with low energy prices and low property prices is hard; colo space reachable from London in often 30%-50% above what it can be like many other places in Europe, and so you'll find managed servers from providers like Hetzner is often cheaper than on prem if your company is in a location like that)
- briffle 5y agoBeen a sysadmin for many years. Your right, for a few computers. Once you start getting into more than a quarter rack, you also need to start worrying about cooling (which also is lots of electricity) and usually things like ensuring the electricity stays on. (UPS, generator, etc). Don't forget to monitor and service all this stuff regularly. Once your past a few racks of equipment, you have generator tests and service appointments, redundant AC, Redundant UPS, dual power to each rack, etc. Dual Internet connection, and a link to your other server room that you use for DR, etc. The costs and complexity quickly escalate after a server or two.
- dhzhzjsbevs 5y agoIn the bad old days we bought our own servers and rented rack space in a datacenter they took care of all the hardware management, we looked after the software. Mind you this was only about 4U worth.
- BryanRamirez 5y ago(I created an account just to upvote and comment on this) Absolutely, nevermind managing OS upgrades and needing to use configuration management to mitigate against drift. It took a lot of effort to make sure that each server was not a special snowflake that could not be reliably reproduced. Also, dealing with vendor warranties, and being on hold with HP (or whoever), then assuring them you're running the latest firmware.. please for the love of god just replace the failed memory/disk/cpu. I found the sheer physicality of computing infrastructure to be a source of exhaustion and burnout. It's a big part of the reason why I'm a software developer now :)
- secabeen 5y ago> Once your past a few racks of equipment, you have generator tests and service appointments, redundant AC, Redundant UPS, dual power to each rack, etc. Dual Internet connection, and a link to your other server room that you use for DR, etc. The costs and complexity quickly escalate after a server or two. This is not always the case. For computationally-focused workloads like the OP describes, without direct customer interaction, it may be reasonable to accept risk of downtime in the event of failure. If you are doing computations that take weeks to complete, and you checkpoint regularly, does it really matter if your computation finishes on Saturday morning or Monday morning? If not, you can probably accept 6 hours of downtime once every couple of years and eliminate all of the redundancy overhead described above. In HPC, the general rule of thumb is buy your hardware if you can be sure you'll run compute on it more than ~40% of the time.
- stephbu 5y agoTo add to this statement - don’t make any investment unless you have a solid plan to fully utilize it for the full length of the purchase terms. This applies as much to AWS @ minute terms, as it does to a rental @ daily terms, as it does to co-lo capital investment @ yearly terms.
- marcosdumay 5y ago> unless you have a solid plan to fully utilize it for the full length of the purchase Hum... I'd say it's much more reasonable to look at the ROI. Making investments to supply peak demand or to hedge against rare risks is perfectly ok.
- stephbu 5y agoFair point, I guess the point is that unallocated resources - space/power/servers etc. can become huge stealth money sinks, eating budget every hour of every day. Being cognizant of the consumption economics before you stump up for resources is important, as is fitting the investment model to match those economics. Setting utilization/allocation targets are just one way of measuring if those models efficiently match. This is true for any service or resource consumed.
- croes 5y agoThe dot-com bubble wasn't about SaaS companies but internet companies as such, basically everything with a .com address. Hence the name. It was more about e-commerce than SaaS. Especially because of the internet data rate in the late 90s.
- vidarh 5y agoWhat it was "more about" is irrelevant the point is there was plenty of SaaS, and plenty of options to host them without owning servers. Many of us here we're around and running internet companies at the time.
- manigandham 5y agoThe quote also says "web-based". Anyways the point is that web/internet businesses were common and growing rapidly way before any modern IaaS provider.
- theta_d 5y agoIn the 90s we didn’t use the term SaaS. It was ASP back then, Application Service Provider.
- edanm 5y agoYou're mixing two different things. SaaS is a business model. ASP is a technology.
- manigandham 5y agoNo, that's a different ASP. Application Service Providers are a business type: https://en.wikipedia.org/wiki/Application_service_provider https://en.wikipedia.org/wiki/Application_service_provider
- edanm 5y agoOh! I stand corrected. Very interesting, I'll be reading up on this.
- 300bps 5y agoNonsense. There were plenty of SaaS startups. I started an ISP in 1996 and had the same reaction you did to that statement in the article. The only thing I’d add to what you said is the article said what drew them to the cloud - hefty free credits.
- vidarh 5y agoI agree fully with this with one caveat: if you're in an location then managed servers can be cheaper than your own colo. E.g. I'm in London, and it's hard to beat Hetzner with colos near enough to me to be practical. Still sometimes reasons to use colos, but I think it's important people consider that the choice isn't just cloud or your own equipment on prem or in a colo - managed servers can get you most or all of the savings too. Agree about scale. Most software devs have no idea what can fit on a single server, and sometimes tend to start wanting complex scaling solutions for things where every possible customer they could ever get could fit on a single server
- the_duke 5y agoIn addition: long before AWS you could easily rent virtualized or dedicated servers. It took longer to provision than EC2 and all you had for storage is a fixed amount of disk, but that was absolutely sufficient for many businesses.
- _hcuq 5y agoI still use them. Easier than fiddling with AWS.
- post-it 5y agoThe biggest thing for me is no surprise bills. Sure, it's pretty unlikely that a t2.small instance and its associated storage and network subscriptions are going to produce a $1000 bill one day, but there's literally no way to set a hard cap on billing so clearly Amazon thinks it might be possible.
- phonon 5y agoUse https://aws.amazon.com/lightsail/pricing/ https://aws.amazon.com/lightsail/pricing/ then...
- deleted 5y ago[deleted]
- ludjer 5y agoAt that point you might as well go with vps. Lightsale is way more expensive and the underlying architecture is way more unstable I have a 1% failure rate for my fleet of instances. Ever two weeks I have a instance is not responding and needs to be rebooted alert from aws.
- manigandham 5y agoDefinitely more process involved, but the requirements were also simpler compared to sprawling modern architectures. I think the overall effort is similar, but was slower due to the speed of communications and paperwork at that time. Getting hard assets is a core part of business in basically every industry, so I found it strange to claim that it was some major obstacle just because it happened to be servers instead of trucks or factory equipment.
- mschuster91 5y ago> Companies also vastly overestimate their scale when their entire business could probably fit on a single commodity server. Indeed, but that's completely leaving out the single most important thing: backups. With all of the major clouds, snapshots are easy to do both at a VM level and data level (e.g. RDS), and the cloud provider takes care that the backups are sufficiently spread to be disaster tolerant. In contrast, when you co-locate you have to take care of backups completely on your own, and with many hosters you can't even influence in which of their DCs your servers will be. If anything, OVHs SBG fire incident should have shown everyone how hard it is to build resilient systems.
- marcosdumay 5y ago> and the cloud provider takes care that the backups are sufficiently spread to be disaster tolerant Except against the disaster of the cloud deciding it's not worth to keep you as a customer, or the cloud having a distributed failure, or the cloud getting out of business...
- BackBlast 5y agoYou need your own backups even if you're running EC2. If for no other reason than the vendor disappears, and you want to recreate the system elsewhere. It's the same problem if you run your own server or on someone else's systems. You need a backup and restore plan either way.
- mbostleman 5y agoOf course. I stumbled on that sentence too. Maybe he meant something else or he is very young. The only difference was that they were called ASPs, not SaaSs.
- deleted 5y ago[deleted]