Why I Dislike EC2
openmymind.net
openmymind.net
S3stat's nightly job takes about 60 hours to run, and it needs to start and finish between 3am and 6am every morning. Amazon kindly keeps 20 machines ready to do that for me and only charges the time I'm actually using them. That's pretty amazing, and well worth the price in my mind.
So yeah, if you need a box to run your webserver 24/7/365, you can find a better deal elsewhere. But that's really never been what EC2 is for. To continue the example, S3stat.com lives in a cage at a colo since, as the author points out, that's a much better deal than running it on EC2.
What Amazon offering is? This is AWS we're talking about. They have a service solution for nearly everything. You're saying in 2013 they still don't have a service for 24/7/365 website hosting?
But, it's fun to point at "elastic" and tell people they're "doing it wrong" because they don't take a name chosen 7 years ago literally. As if somehow the service (called EC2 virtually everywhere -- not Elastic Cloud Compute) could never evolve beyond that initial use case. Incidentally, the "elastic" in EBS must have a different meaning because one of its primary selling points is that it's persistent storage.
The point is absolutely not that EC2 never evolved beyond its initial use case and isn't good at other things.
The point is that while they have 24/7/365 hosting services, there's never been any reason to expect that they would be better at it than anyone else. So why do we continue to see blog posts about not liking EC2 with vague complaints about the horrible price-to-performance ratio getting lots of upvotes?
It's not an arbitrary name, elasticity is a defining concept of "cloud".
>As if somehow the service (called EC2 virtually everywhere -- not Elastic Cloud Compute) could never evolve beyond that initial use case.
EC2 is one tool. There are other tools in the Amazon box for other use cases [0] and other boxes from other providers entirely.
>Incidentally, the "elastic" in EBS must have a different meaning because one of its primary selling points is that it's persistent storage.
It's elastic because you can allocate and deallocate rapidly and pay only for what's allocated at a given time.
If I need on-demand instances these days, I'll do it at Linode. They bill to the day, so you don't need to commit to a month for temporary instances. It's not as scriptable, but it works and doesn't cost a fortune over renting hardware either. More often, I just get servers with more CPU cores and more RAM than I need so there's plenty of room to absorb spikes.
We use ELB (Elastic Load Balancer) with an auto-scaling group behind it. The instances get added or removed based on the latency reported by CloudWatch/ELB. During the course of a day, the number of EC2 instances running can vary from 8 to 25.
Usually 8 is enough, but when spikes happen or when the capacity of instances to process stuff drops (which does happen in cloud-computing, based on what neighbours you have and what they are doing), then new instances are started in a matter of minutes.
And this billing by hour does save us a lot of money. Because 8 instances is enough, until it isn't and the traffic is so huge that it can choke and freeze 8 instances.
Incidental, this ability is one reason we moved off Heroku.
I'm not heavily experienced in cloud offerings, but it's far easier to manage the AWS stuff than the rackspace - the DNS management is quite flexible yet couldn't be simpler with AWS's 'Route 53', but with the part of Rackspace we were using it wasn't 'all in one place', which made it hard to peruse or alter.
I found support at both places to be upbeat and knowledgable, though I don't know about timeliness since I've only really lodged low-priority tickets. AWS does need more domain knowledge in order to understand its flexibility, and I've gotten a good workout from my $50/mo support add-on.
I appreciated their honestly but they were lacking a few required services for us at the time.
"EBS would fail often too"
I'm currently thinking about using RDS in a production environment and it would be interesting to know the limitations.
But, that's why AWS gives you RDS backups, AZ failover, etc. -- the backups won't fail (they're stored on S3), and with AZ failover, you can make downtime vanishingly small. But you need to actually do that.
A lot of people seem to confuse S3's 99.9999...% reliability with the EBS-backed stuff, which you must plan for eventual failure with.
plan for EBS to fail
plan for RDS to fail
'snapshot early snapshot often', as snapshots will help you in case of a failure
there is no automatic snapshot functionality ( yet? )
plan how to snapshot an EBS RAID (Filesystem, uptime)
Its computing and hardware, absolutely everything fails eventually.
2. EC2 is just one item in the package called AWS. Hence, if you just build something more than just "web-app with *db" at the back-end, say a full blown platform, then I know no other option for you to get the full stack integrated API for Data-warehouse, DNS, Load-balancing, auto-scaling, billing, etc.
3. Speed is sometimes over-rated. You should be be speedy where it matters more. That is, how fast can you redeploy your entire cloud from scratch in case of a disaster should be more interesting to you than if a webpage takes 20 more ms to get to the browser. In our case, at AWS, it is a matter of < 20 minutes.
1: https://aws.amazon.com/compliance/ and https://aws.amazon.com/security/
And 20ms? Try more like 300ms+ difference. Hell, sometimes a full second or more for some sites. Anyone who says total disaster recovery time is more important than total latency isn't running anything remotely to scale.
Those are cheap services which improve speed dramatically.
Network is, in fact, a major player in the latency, and by being globally distributed, configuring Route53 appropriately, and integrating CloudFront CDN, a given web-app gets a boost that I doubt a faster computer can beat.
The EC2 network also has mysterious packet filtering on it that prevented IPSec tunnels from working correctly.
I've managed to leverage CDN and globally distributed servers for a fraction of the cost of Amazon services just fine, and I have the added benefit of 100% full control of all aspects of it, including the network.
A good analogy is that EC2 is like an interpreted language versus compiled - you can get a lot done and it's easier to get started, but if you're really serious about performance, you need to program in C.
Personally, I'd rather have 20ms shaved off my users time than a 20 minute disaster recovery time. Disasters happen perhaps once a year (on AWS, possibly less on dedicated servers), people are loading pages every day.
If you have "users", then you might be right, as no harm will be done, if once in a few years, their free service will be shutdown for 18 hours.
However, if your customers are running core and critical parts of their business on your system, this part becomes a significant factor in the equation.
My nontechnical boss doesn't know about the 20ms difference (thinks her computer is slow?) but an outage is visible like the difference between day and night.
I know it's just a fabricated number but the point is that the server you're running on won't make a difference to the user experience. And, probably in the case of the differences were talking in these machines, a user would never notice it.
Edit: meant to say, I agree with you.
While the compliance and security links are impressive, AWS still doesn't offer a BAA agreement for HIPAA/HITECH compliance.
There are plenty of health care companies that are held back from AWS for this single reason.
Surprisingly enough Microsoft is leading in this respect (or not, given their historical enterprise focus...) - http://www.windowsazure.com/en-us/support/security-and-compl...
Updated: AWS also has a whitepaper on Creating HIPAA-Compliant Medical Data Applications with AWS [2]. Looks like this is support on the standard non GovCloud stack.
[1] http://aws.amazon.com/about-aws/whats-new/2011/08/16/announc...
[2] http://media.amazonwebservices.com/AWS_HIPAA_Whitepaper_Fina...
Our experts advise a safe, CYA approach and mandate a BAA agreement is in place with every partner touching sensitive patient data, even if encrypted and protected on multiple levels. Thus far Amazon is not accommodating to such a request.
Other's have their own opinions and, in the end, we all weigh the risks vs rewards (including Amazon itself - I'm sure they've plenty of reasons of operating in their present gray area).
I'm not arguing that it makes sense, just that it happens.
2. We use quite a few more things than EC2 for our systems. - SQS eliminates the need to build / manage a queuing system. - DynamoDB/SimpleDB eliminate the need to build / manage a distributed data store. - OpsWorks eliminates the need for a DevOps team (mostly). - ELB eliminates the need to build / manage a load balancer. - SES seamlessly takes care of out-bound mail. - Direct Connect gives us a way to extend our DC tools into the "cloud". - And to top it all off, I can bring up any/all of these services at a moments notice, run some experiments, and then shut them down when I'm done.
I don't think there are very many vendors that can help us do these things with this much flexibility. Yea, AWS can be expensive, but we feel like its worth it.
Pick your language though. With terrible forking performance, any process-based execution environment is going to have similar issues. And I found running a servlet container on anything smaller than an m1.large to be an utter waste. 1.7 GB RAM isn't enough for many JVM-based apps and threading could easily overwhelm the system. Anything less than high I/O capacity just can't keep up.
If scalability matters, you should have picked a better platform. Ruby/Rails/Passenger is a terrible platform for scalability / performance. And even if AWS is slower than other solutions, the first problem you have is your own heavy-weight app and the platform you've chosen. 15 concurrent requests per second makes me chuckle.
Things evolve and whole hog rewrites are difficult. Nowadays we run in JRuby and things are quite a bit better. But we can't run on anything smaller than an m1.large. The low I/O and meager RAM in a c1.medium preclude its use. (BTW, that's where a lot of the original 15 came from -- with a process using 100 MB RAM and only 1.7 GB available, it's hard to squeeze much more out of that).
But the larger point is with virtually any other provider you can pick a configuration that matches the needs of your app (rather than the other way around), don't have to fight with CPU steal, don't have to fight with over-subscribed hardware, and don't have to deal with machine configurations from 2006. Yeah, Rails is never going to outperform your Scala web service. But if the app would run just fine on the other N - 1 providers, then it's disingenuous to gloss over the execution environment as well.
Run it on top of JDK 7 and use the CMS garbage collector, as JRuby (and Scala) tend to generate a lot of short-term garbage and experiment with the new generation proportion (something like -XX:+UseConcMarkSweepGC -XX:NewRatio=1 -XX:MaxGCPauseMillis=850). You can also profile memory usage (make sure you're not stressing the GC, as that can steal away CPU resources) and for that I believe you can use Java profilers (like YourKit which is pretty good).
Also, try to do more stuff async, like in another thread, process or server. Use caching where it's easy, but don't over do it, as dealing with complex cache invalidation policies is a PITA.
In the case of Cassandra, disk I/O was a constant issue. So, we grew the cluster much larger than would be necessary on another provider. We also lost instances pretty regularly. If we were lucky, Amazon would notify us about degraded hardware, but usually the instance would stay up but do things like drop 20% of its packets. Replacing a node in Cassandra is easy enough, but you quickly learn how much their I/O levels impact network performance as well. Nowadays Cassandra has the ability to compress data to reduce network load, but you then run into EC2's fairly low CPU performance.
The CPU-bound application I mentioned wasn't so bad, but we paid heftily for that ($2.40 / hour - some volume discount). At the high end the hardware tends not to be over-subscribed.
Performance, price, and reliability were all issues in all cases. Those are not EC2's strong suits and haven't been for a while.
Unfortunately we also need auto-scaling capabilities and map-reducers and stuff. Maybe Google's new "Compute Engine" service will prove to be better.
If AWS were so expensive and "not worth it" what are the guys from Netflix smoking? ;)
Also see this AWS cost analysis from TripAdvisor Technical Operations team: http://highscalability.com/blog/2012/10/2/an-epic-tripadviso...
"Combined cost for each datacenter is about $1.3M per year." ... "If we spent the $1.3M per year on a complete EC2 site instead, we could afford the following architecture, provided that we used one-year reserved instances." ... "This means that we could add more than 60% capacity our current configuration"
Also, they get preferred pricing and status at Amazon that normal people don't get.
Netflix probably doesn't pay what you and I pay. Also, for every Netflix, you can find 100 examples that use dedicated or collocated.
So while AWS might be completely worth it for some people (it is for us), Netflix isn't the best argument :).
Considering that they're a publicly traded company, they have a fiduciary duty to watch all costs. Though server costs don't compare in relation to media licensing, I'm sure they pay some attention.
This is down to familiarity of tooling, not some intrinsic advantage that EC2 has over managed dedicated hosting. The simple matter is that there just isn't the maturity of tools around automated provisioning of dedicated hosts, which makes them seem higher overhead.
> If AWS were so expensive and "not worth it" what are the guys from Netflix smoking? ;)
Simple: Netflix have very bursty load, so it costs them less to pay the EC2 and virtualisation premium than it would to keep an equivalent amount of dedicated hardware on warm standby. Is your load bursty? Then EC2 might make sense.
EC2 (or any cloud virtualisation platform) will always lose in a shootout with managed dedicated hardware, unless the shootout parameters are provisioning time and tooling, simply because EC2 is managed dedicated hardware plus an extra layer of stuff on top that has to be paid for.
/shameless shill + happy DO customer
It's ok for a dev box or playing around, and it's definitely cheap, but I wouldn't trust any production servers on it. _Yet_. I do see they improve at a very impressive pace, with new features becoming available regularly, so things hopefully change for the better... It's still nowhere near being a match to AWS, or even Linode.
But once you get up and running, you will realize that this comes with a great cost. EC2 absolutely sucks in terms of raw performance. I also notice variation in performance of machines on different times of the day, and between machines.
Amazon has done a great job at selling "the cloud", and I can see many CXOs buying into that. But the fact is, renting dedicated machines from a good provider isn't exactly that hard. They take care of a lot of things for you.
EC2 is good if you have wildly varying amounts of traffic such that you need to really have that kind of elasticity in your infrastructure. However, for most businesses, especially web apps, that's not the case.
I love the idea of their cloud services, but the reality is a decidedly less attractive beast.
Consequently AWS has to rate-limit API requests to avoid taking another AZ down.
Maybe this has changed though, but we'll probably have to wait for another disaster to know!
---
But of course, an AZ shouldn't be your infrastructure's single point of failure!
These decisions were made by companies that started off believing fully in the promise of elasticity, and gradually shifted to less elastic architectures as they experienced issues. That said, it's worth noting that these are firms with very high costs of downtime, so the magnitude of failures was very high.
How much of AWS' popularity come from it just being a safe choice, like a cloud version of "No One Ever Got Fired for Buying IBM"?
AWS' popularity comes not just from the wide array of decent, well integrated and cohesive services e.g. S3, SQS, ELB, ElastiCache but also all of the third party services that are hosted within the AWS network e.g. MongoHQ, IronMQ/IronIO. AWS is very much an ecosystem.
If you are building a new app from scratch there a lot of benefits to having others manage the commodity parts of your infrastructure.
The radical majority (99.999%?) of all sites on the web can easily be run by a cheap dedicated server. And I'm not talking Softlayer, which itself is expensive in the world of dedicated hosts; there are several better priced providers that are nearly as good as Softlayer.
EC2 is never going to appeal to the bottom 99% of the web, until their prices come way down (and Amazon may never care about that). Dedicated hosts will keep offering more and more ooomph per dollar. The demands on a typical site in the US market (prime AWS customers currently) are not going up much per year at this point, as web usage is no longer growing much for the first world. Meanwhile hardware and bandwidth for an average dedicated server just keep getting better.
Services that used to cost me $300 to $500 / month to run four or five years ago, I can now operate for 1/3 that price on even more powerful dedicated servers.
Using the Cloud isn't only about instant scaling and per hour billing. Those are useful features, but mostly for specific use cases.
--
The Cloud it's about the ability to have software that controls the hardware.
It's about being able to orchestrate automated failovers that provision new servers.
It's about being able to have services that grow and shrink depending on usage.
It's about being able to replace your app servers with data crunching servers at night and relaunch new app servers at day - all transparently.
Of course, those are just a few examples, but the general idea is that programmatic access (APIs) is the big thing. The rest is secondary.
---
Is is, however, true that this is not useful to everyone.
On the topic of succeeding using the Cloud, it's indeed difficult. That's why companies are building cloud management tools to help users do this.
Disclaimer: I work for one of these companies.
Nothing stops your from spinning up data crunching EC2 instances at night either, if you want to, and if it really is more cost-effective for you than having VM on your dedicated hardware.
There's plenty of API's available if you want to run your own "private cloud" on those dedicated servers too. I never deploy outside VM's any more, even though I also mainly use dedicated servers.
EC2 is cost effective if you truly have really short term (< 4-6 hours per day) batch processing needs. It continues to shock me how many people take the pain and cost of dealing with EC2 for more typical web app usage.
This is a great idea on paper - but running your baseline infrastructure at your dedicated provider and the rest on EC2 is definitely a challenging task.
Not that it's impossible, but that's probably going to be extra work at the app level.
---
Running OpenStack / CloudStack, or similar software on dedicated servers is indeed a relevant solution too, but this is an extra maintenance cost to bear in mind.
I think this blog post touches on the phenomenon: http://www.ravellosystems.com/blog/the-unbearable-lightness-...
Nonetheless, the values I see in EC2 and AWS come in the API, role management, and the centralization of services. Being able to automate everything is outstanding (even if many of the APIs feel very young). Allowing anyone in the organization access to the management console with appropriate privileges is helpful, and something that I haven't seen available from other providers - at least not with the level of customization that AWS provides. Also, knowing that just about everything is handled in one place makes things easier logistically - it's small overhead, but managing DNS and CDN and Hosting all in the same interface is convenient.
Hosting decisions must be made on a case by case basis; but it's wrong to avoid EC2 (and AWS) simply because you can get better performing servers elsewhere at a lower cost per time period.
And of course, the second letter stands for compute. If you find yourself using words like traffic instead of computation and discussing the finer points of the per-hour billing feature instead of how many CPU-hours of jobs are enqueued, you should definitely consider that you're trying to use a tool that wasn't designed with your needs in mind.
That said, AWS in general has a lot of useful tools for web developers, and certainly one use-case of an elastic compute cloud is temporary development instances.
I totally disagree. OK, maybe it takes a bit more time to set everything up, but when you have it all up and running (AMI's, Autoscaling, etc.) you have a robust setup that can scale when you scale (up or down). Adding a new instance literally only takes some minutes. Try that with a dedicated setup. It's more expensive for sure, but comes with a lot of flexibility.
What I see as an EC2 (or AWS in general) issue / challenge is that it's hard to switch providers. When you use S3, SQS, Cloudwatch, Elasticache, Cloudfront, DynamoDB, SES, Route53 your code is totally integrated / adapted to AWS. You can't take your code and deploy it on a different setup elsewhere.
These issues are why we started Uptano, really just to scratch this itch for ourselves. Plug: https://uptano.com
The thing is, EC2 really was neat when it launched, but there are so many things that can be improved upon. Amazon has moved surprisingly slowly in improving EC2 itself.
So, my take on Amazon EC2: you want to use it when you are small (i.e. don't really care about performance) or when you are really big (when you can get "special" deal from Amazon and dedicate a lot of internal resources to make it work). In other cases a better option might be a mix of dedicated hardware (servers and networking stuff) and virtual servers at a managed hosting provider that would allow you to create the setup that works best for your project.
These services make it an easy decision to stick on AWS, and sadly ec2 as well
This isn't true. Reserved instances still use per hour billing, just at a discounted rate.
The other key difference is that reservations apply to hours used, not specific instances, which means you can do things like buy heavy instances for your 100% utilization level and medium for the amount beyond that which you commonly but not always use.
Also in the post is that for the scenario you're describing, having dedicated servers handle the base traffic and relying on spot instances for the spikes, is much more cost effective.
Another thing to take into account is inter-datacenter network reliability. I have personally ran a hybrid system (dedicated + EC2) before and suffered a routing issue. The upstream provider for the data center that my dedicated machines were in suffered a routing outage to EC2 US-East region (or at least to the AZs that my instances were in), and my EC2 web app servers could not connect to my DB for around 10 hours (during the day time too). If you have a hybrid system, during peak hours (where you have lots of EC2 spot instances serving traffic), networking issues could result in unexpected downtime. This is of course, in addition to the regular SLA downtime you get from either the dedicated provider or AWS, which is not an issue if you have everything hosted together, but could become an unavoidable problem if not.
In terms of inter-datacenter network reliability: You have to deal with this if you want reliable hosting anyway. If you spread your database and app servers across data centers, yes, you are begging for problems and the problem is that your app is not designed for resilience.
But you can easily enough do "hybrid" within the same datacenter, if you opt for any of the number of EC2 alternatives from companies that also do dedicated hosting.
Inter-datacenter network issues are less of a problem when your datacenters are from the same provider, because they are responsible for making sure the connection is good. Plus, when problems do occur, you can troubleshoot fairly easily (when I had the routing problem with dedicated provider + EC2, I had to bounce back and forth with the network support for both a few times before one of them admitted the routing issue with the upstream network provider) as you are dealing with a single company.
I understand the hybrid solutions that other providers such as softlayer offers, but I was mostly addressing the suggestion of using dedicated + EC2 in the original article.
Only if you choose your systems so that they can't be used across both platforms. I don't see why anyone would do that if they want to run a hybrid setup.
> Inter-datacenter network issues are less of a problem when your datacenters are from the same provider
If your data centers are from the same provider, your added degree of resilience is much lower.
> because they are responsible for making sure the connection is good.
That doesn't help you when one of the data centers goes out entirely. Such as when the power needs to be cut for fire brigade safety due to a fire alarm (yes, I've experienced that), or the supposedly redundant UPS's triggers failsafes and causes the entire site to go down (experienced that too), or when one of the sites see cascading failures take out heir entire network (seen that happen too).
Assuming you will have live, working network connections between your locations, and/or that all your locations will stay online is pretty much guaranteed to cut your availability.
Basically, if your systems can't operate independently, adding an extra data center means adding more failure points.
These days there are so many hosts that offer combination of colo + dedicated servers + cloud services that you can seamlessly do both even if you don't want to deal with more than one provider.
The only things I get a big price/performance advantage over AWS for are things I might as well host on my desk, and even there it's dicey.
Hetzner and OVH provide the starkest contrast when it comes to price. They are also pretty well respected.
There's a million other choices in between. webhostingtalk.com is the best place to get more info..but I can give you names that have been around for a long time and tend to be liked by customers: webnx, singlehop, 100tb (softlayer reseller), reliablesite.net, hivelocity, netdepot. The list goes on and on, but if you want to see price differences, check them out.
Those are specials but their pricing in general is very good. SoftLayer has some great stuff most hosts don't have but you pay for it.
Quite a premium. Even adding in the salaries for my admin team only drop it a few more percentage points.
In February our website was top 3,000 on Alexa. 150 requests a second on average looking over that month. Those are dynamically generated pages, since all the static assets are served by CDN.
What handles all that?
3 servers running a PHP application. Oh, and the Postgres database is sitting on one of those servers and replicates to one of the others.
We can do it with 2, but we have 3 so that if some of them dies we don't have to worry.
These are the cheapest servers that Softlayer offers and they run at a low load average.
Then randomly the bank won't work, all banks in the region will shut down randomly and you're stuck without money, and you need to pay rent but you can't.
You are invested in certain banks in the region but sometime s it feels like the bank has noisy neighbours, and it takes a while to withdraw money.
I'm happy to pay a premium to not have to worry about the countless things that AWS deals with. Whenever people complain about AWS having downtime I have to wonder how sure they are that their uptime track record would be better.
An app I am running uses ec2, s3, sqs, ses, rds, swf, elb, elasticache, cloudfront, cloudwatch, route 53, and opsworks. Take any of those out and you give me a potential headache, time sink, or out-of-scope responsibility. It all just works and while I am sure I could save as much as 50% by going cheap and rolling it all myself, my time is valuable, I'd have worse uptime, and with proper reservation of resources my aws bills are, in relative terms, marginal.
M3-2XLarge = $720 per month, 60% = $432
As a softlayer customer, I would be very surprised if you can get 2620/64GB/4TB disks at this price range, we also consider ourself not a small customer, but for the above config, I guess we need to pay $800+. (after discount)
http://www.100tb.com/server-deals/
We get access to Softlayer's vpn, their control panel..pretty much everything.
Years ago, at a different company, we used Softlayer proper...you can negotiate prices down by huge amounts..even so, they are overpriced when you take into account their reseller. (Note, I know the deal says 48GB, but we have 10 or so of those servers, and they all came with 64...ssshhhh).
We have several 48GB machines ordered directly from SL, even after so called discount from SL's sales, we need to pay around $5xx per month.
I pick the min. cost for EC2 as my point is to show you that SL isn't much cheaper by a lot (at least using the official channel)
The folks who claim it is more expensive to run AWS over on-premises infrastructure are either not counting their total costs (power, staff, off-site data storage, co-location) or not architecting things properly on AWS.
I definitely agree with you on the disk failures, and that's something I need to bring up with our account manager.
The above said, the network has been solid for us at SoftLayer for the last 1 1/2 - 2 years (things were rocky for a little while before that as the client base outgrew their capacity). Of course, your systems might be in different data centers to us so mileage may differ.
Doing it again, I'd pick Hetzner over OVH. The OVH machines are great (weird disk partition though) and they've worked reliably..but the management console is horrible and while the support is fast and helpful, it tends to take a couple back and forth to get to a meaningful conclusion.
As a consultant recently I was tasked to build a service which (rather not say), I had good data on requests per day, total data storage, factored in ELB, etc.
The cost was less than 2K a year. Now consider that the company refused to buy hardware or pay anyone to support it because they had a full staff of sysops maintaining their (rather not say) at great cost in their own data center.
2K is absolutely nothing to a company. Most of us are not Netflix or Dropbox. Don't pretend you have those kinds of problems if you don't. It could have cost 3x that per year and they still wouldn't have noticed it.
AWS for manageable workloads is dirt cheap at scale. I think you'd have to be nuts not to use it.