There are more costs to Serverless than just CPU and RAM — and for many users, the additional cost categories of API Requests, Storage and Networking will be the major cost drivers.
I am not sure to what the op was referring, but I’d make sure to plex your connections through a configured connection pool to ensure the highly liquid lambda compute doesn’t suffocate the database.
Traditionally, a web application creates a group of always-on reusable connections (a pool) to a database server since setting up the connection takes time and each connection uses up resources on the database server that could otherwise be used for computation. If there are more connections to your API that require the database than there are connections in the pool, those requests are queued and handled when the next connection is freed. These connections are then closed when the app shuts down.
The problem on Lambda is that you can’t persist any application state beyond the function call itself, so you can’t take advantage of connection pooling the way you normally would in a self-contained webapp. Without some kind of middleman, each database call will require you to open a new connection to the database and close it when the function ends. This becomes catastrophic for the database server as the number of requests scales up.
It’s easy to knock over anything with bursty Lambda loads. I have successfully maxed out AWS Redis, kinesis, kinesis streams, and S3 with massively parallel Lambda work. One of the things that I haven’t figured out is if there’s a sane and simple way to implement backpressure on Lambdas.
the extra moving parts aren't...but I think the point was to remove the existing moving parts (installing and maintaining a server instance). they just got it wrong.
it would save everyone a lot of time and energy to not have to deal with server instances, so its likely a better model will come along. persistent storage in the presence of scaling and concurrency is a bit of thorn though.
its not that people cant understand [salt, chef, ansible, terraform], its just a non-trivial amount of human effort, error, and upkeep just to say 'run my program'. kind of a shame that every shop has to have one or a few devops people on hand to do that.
I guess it mostly stings when there is a critical openssl update, or something analogous. Despite the ideal of continuous integration and lightweight deployment - none of the shops I've worked at lately can make than happen in the 10 minutes its supposed to take.
With all due respect, I think it’s laziness. Most of the good soft ens I know spend the one - two hours or so it takes to get familiar with these systems.
> If you're using Terraform + modern config management tools I find it a breeze. I feel like this is a weak argument.
Writing a back-end for a mobile app right now. I need a few CRUD calls, but I also need stuff to stay in real-time sync between users.
So far I've been able to sprinkle magic cloud fairy dust on things, solve auth, solve concurrency, and deployment is super easy.
I originally thought about doing it on a VPS. Then I realized I'd have to deal with a bunch of issues that I Just Don't Want To Deal With Right Now, especially since I am trying to get an MVP out ASAP to validate my idea. The various cloud providers all offer nice, well tested, SDKs to do all of the nasty/boring work for me, and a single call on my command line deploys everything.
Serverless fits a niche where a container or entire VM is overkill, or if you require an environment to run arbitrary code from users without the complexities managing such an environment entails.
IMHO neither moving to the cloud or serverless entirely are inevitable unless you have unlimited resources and don’t mind contributing to Amazon’s margins, but both have their places when time is more valuable than infrastructure (although as you require additional capacity, it’s time to refactor your use of infrastructure moving down the abstraction layers).
Disclaimer: my org has and intends to keep quite a bit of hardware on prem at our own datacenters, but also spends mid six figures on AWS monthly
"Serverless" is a silly name because there are of course still servers. Peer-to-peer architectures could perhaps charitably be called "serverless", but I digress.
To me it sounds like this whole "serverless revolution" is just the product of Amazon's PR team who found a nice term to befuddle and bedazzle know-nothing CEOs.
Look, at some point, my "wireless" internet involves wires, but I don't really have to worry about managing them, so it's wireless in the ways that matter to me.
That's a fair point, but wireless internet is a different mode of delivery to your house, whereas "serverless" is just adding a layer of abstraction, and I don't really think that these things are analogous.
Well, you’re also completely ignoring many tradeoffs. For instance, it is cheaper to use 10k concurrent lambda invocations than it is to spin up the equivalent ec2 instances. There’s also the dev time allocated to maintainint the server infrastructure itself.
Serverless may be a disingenuous term, but it does refer to a useful thing.
Very funny. No, but what if I called a virtual machine CPU-less. Bad name? I would say that is. Also treating long running task as a little demon performing a task is more allegorical same with killing a process. I am not sure I would call it being server-less allegorical.
You're confusing abstraction with implementation. The architecture is serverless. The implementation is running on a server. But the whole point is the users don't have to worry about the implementation, just the architecture.
> Cold starts. This isn’t the time to dive in deep, but it’s a main reason why some companies decided against going Serverless.
Cold starts as an issue? I mean, all you have to do is create a CloudWatch event (or cron if you want an explicit server involved) to fire the Lambda function every few minutes and you're all good. Sure, if you get heavy traffic, I suppose you could have multiple containers running simultaneously? But that's also easy enough to handle w/ CW events.
Because the cost and level-of-effort difference between those two options isn't comparable. Firing a function in a way that keeps it awake but uses no perceptible resources is simple and basically free.
It's probably not as easy as that. Lambda functions run in a container. If you have a spike in traffic, you may have 10 different containers handling requests. So should they keep 1 container always up, or 3, or 10. I suppose you could have some ELB-type rules to "auto-scale" new containers...
They do for me. It's basically free to fire a function every 5 minutes, have the function immediately close, and have that Lambda container sit around for another ~10 minutes "hot" and waiting for a real request to handle.
Aren't these cloudwatch/cron events basically doing exactly that? People are keeping their functions hot and not using resources but AWS is having to keep those containers up 100% of the time
Yes, but by making it something you have to laboriously set up rather than a default 95% of people won't do it, and you can afford to let 5% do this hack without jacking up low-end prices.
When you think of it that way, in practice it really is the exact opposite of the “Serverless” buzzword - it’s 100% definitely absolutely requiring a persistent centralized remote server.
Decentralized solutions 100% definitely absolutely do not.
My current work project is trying to switch to a primary serverless architecture. I'm trying to fight it but know I'm going to lose.
I don't have any problem with "serverless". Years ago I wrote a nginx handler that routed to .py files and ran them inside an lxc container, while at a hosting company. Fronted via haproxy, and documented with sphinx automatically.
My problem is the hidden costs. Sure lambda requests are low cost. But what about API gateway, dynamo/rds access. Then I'm writing a basic crud app. Low-performance low request rate, noncritical. There is this additional complexity, that just isn't necessary. Every day at my job I'm thinking to myself it doesn't need to be this difficult.
My usual route is django, django admin, and django rest. With an haproxy in front for load balancing. Dead simple and easy to work with. It's passe sure, but KISS. The alternative here is an api and a frontend. Several more projects to maintain. Tuning the projects to meet lambda size requirements/standards. The return on investment is minimal to me. If you can't automate managing a fleet of containers or vps instances then why're you here?
The vendor lock-in, is insane to me. You're pretty much at the beck and whim of the provider. They raise the prices, what're you going to do. You either go with the price increase or do a rewrite.
As I was sitting in these architecture meetings on moving too lambda. I was hearing several new packages/repos. New CI/CD, and configuration to maintain. During the meeting I scratched out a POC using EC2, Load Balancer, RDS and django to do what they were saying with half the code. But nope gotta be lambda.
In the 11 year history of AWS, I don't think they've ever increased prices for anything. I'm pretty comfortable with their ability to avoid it in the future.
An 11 year history is hardly worth betting what could be the future of your company on. Especially for something just slightly more convenient than what can be built in-house.
> An 11 year history is hardly worth betting what could be the future of your company on. Especially for something just slightly more convenient than what can be built in-house.
So you can build a globally distributed, redundant, eventually consistent object store with high availability easily and conveniently and without allocating developer time that could be better used building..oh I don't know, the actual business logic? Not to mention ongoing maintenance and its expense.
It's ridiculous to suggest that the entirety of the AWS offering is something that is just slightly more convenient than what could be built in house.
S3 is not globally distributed. Each region is fully independent of each other. If Virgina is nuked, you lose anything in us-east-1. I’ve confirmed this with AWS staff because of a prior HN discussion :)
The ease through which Amazon provides the ability to architect incredibly globally redundant applications is unmatched. But your business probably can’t afford to implement at that scale, Amazon or otherwise (geographically load balanced DNS, multiple primary databases across regions and their associated followers, replicating S3 objects from all primary region buckets to secondary regions, instances for each application running multi-AZ in multiple regions, etc).
Not speaking about S3 specifically but overall I disagree. Assuming there’s a business case that requires multi-AZ or multi-region redundancy of multiple services it’s hard to match AWS in terms of price and simplicity.
> Cross-region replication is a bucket-level configuration that enables automatic, asynchronous copying of objects across buckets in different AWS Regions. We refer to these buckets as source bucket and destination bucket. These buckets can be owned by different AWS accounts.
Casually underestimating the effort to build something by at least one order of magnitude is a favorite pastime on HN. The Dropbox thread is the canonical example.
I wish people are upfront about conflict of interest while writing articles like this. The author is the CEO of spotinst, which is listed in the last table as 2x-10x cheaper than any of the other FaaS options. The article is basically marketing copy devoid of technical details.
This isn't a conflict of interest. It's developer marketing. A Cloud Guru, the publisher, is a company that sells developer education / training - should they have disclaimers explaining that they make money by selling education before every blog post or comic they put out? Amiram is providing important contextual advice for developers, PMs and executives, and has the added benefit of having a real product in market that will solve these problems for you.
Most of HN is thinly veiled marketing supporting special interests. I think a huge part of the value of HN is lowering the barrier to entry to build great companies by providing a platform to announce and promote your product / team / etc. as well as educate people with quality content. We celebrate "Launch HN" and funding events, and are going to criticize a founder for building something awesome and talking about it? That seems a bit silly to me.
> This isn't a conflict of interest. It's developer marketing.
> The article is basically marketing copy devoid of technical details.
So since you agree with OP that it's marketing, _perhaps_ it's not a stretch to suggest that it's a bit shady for the CEO of Super Cheap Cloud Product to author a marketing piece decrying the hidden costs of OMG So Expensive Cloud Products as though it's just helpful advice?
> I think a huge part of the value of HN is lowering the barrier to entry to build great companies by providing a platform to announce and promote your product / team / etc. as well as educate people with quality content. We celebrate "Launch HN" and funding events, and are going to criticize a founder for building something awesome and talking about it?
Apples and oranges. There's a big difference between "check out this thing I made" and "these products all have somewhat opaque problems _by the way I'm CEO of a competitor_".
Developer marketing != valueless. Every single $B dev co you know has invested millions of dollars in developer outreach and content. It seems the issue is that there's no "technical details" as if a post titled "the hidden costs of serverless" would be about anything but costs. Perhaps the original response expected "costs" in terms of technical debt - in which case, that actually is covered as well, making the criticism a little underwhelming.
If you don't agree with the article, that's one thing. Can you pick out anything in the post that's counterfactual? Look - I'm the CEO of a cloud product that, in some sense, could be considered competitive with Amiram. I've made plenty of upvoted HN comments and Medium posts talking directly about our company and what we do - hell, there's one posted here if you scroll down. I take a great deal of pride in it, and I'm very enthusiastic about the future of the space. It's for that reason I consider the criticism a little unfair.
If the criticism is simply, "be more direct with your marketing and assert yourself and your company" --- that's totally fine. But dismissing an entire article because it's actively providing advice and context because the CEO runs a company in the space (wouldn't that put him in the best position to understand the market?) is... well, like I said, kind of silly.
If the above is, in fact, the actual criticism - perhaps we should ask A Cloud Guru if they'd be more willing to allow promotional posts to feature partners and neat products. A big problem with content marketing (generally) is the people who control the flow of content often ask for pieces to appear as neutral as possible, where a huge chunk of motivated content producers are actually trying to push a product or service (platform, consultancy, themselves and their career, their open source, you name it).
Agreed. Ultimately we all want the best software to win. Which means we sometimes have to hear people out, regardless of whether there's self interest involved on the author's part.
I don't think we all want the best software to win. If you're the CEO of a software company then you want your software to win even if you know it's not the best. You might choose to write articles about how the other software is actually worse because there are lots of hidden costs. If you did that then you'd need to make it very obvious that you have a partisan opinion though, otherwise it'd look quite dishonest.
Yeah content marketing / developer marketing is really valuable -- to the company. That's why companies spend a ton of money on it. It doesn't necessarily imply there is massive value for the reader, although that can be the case.
Having run content marketing, I can say that it helps reader substantially to know an article is written by an interested party.
For example, if I were an expert in a field with two options A and B, and I ran a company that did only A, I would be tempted to release true facts that support A only. None of the facts released A would be wrong -- all would be correct. I could say "find a flaw with any of those arguments" -- and none can be found!
But if a reader were to infer that A is much better when she reads true facts selectively released to support, she would be substantially wrong. Moreover, she would be able to deduce that if she knew I were rooting for team A. This is why being so hidden about your position is shady.
I agree that the facts, when collected from many sources, help the reader a lot. But if the goal is to get the reader to make the right decision, the marginal article with "selective true facts" can be a curse rather than a blessing.
Well...it does say the author is CEO of Spotinst in the author profile above the article title, and also clearly states "This article represents the opinions of Amiram Shachar, CEO of Spotinst." right above the first paragraph of the article.
Maybe the article has been edited since it posted here, but I don't see any reference to Spotinst product pricing. I only see IBM, Amazon, Azure and Google services in those tables.
You may not have found the article useful, but as a "serverless" noob, I found it worthwhile. It certainly wasn't "devoid" of technical details.
The hidden cost of all cloud based software. Even the cheapest cloud (seems to be Google at the moment) is 5x or more of the price of an equivalent dedicated server (2x for "compute", >20x for bandwidth, so 5x is somewhat average. And that's compared to "normal" dedi providers. Ok to use Leaseweb, Hetzner and OVH ? Make it 10x more expensive).
Since VPS's exist cloud doesn't even make sense for the smallest websites anymore. Ironically VPS's predate and are even the basis of cloud systems.
And there's the intangible technical debt that cloud imparts. Whichever cloud you pick, in the future you'll change. That's how the world works. Switching dedicated service providers is a complicated ops problem. Switching cloud providers is a full rewrite of everything AND a complicated ops problem. Just being on the cloud, by itself, forces you to put in serious technical debt.
I don't understand, even after using cloud at work, what those cloud systems provide that can't be done, better, cheaper, and with less relying on a single organisation, on dedicated service providers.
I mean Google's hypervisor is good (very good), but it still imparts significant costs compared to bare metal.
It's fashionable to use cloud services and people don't really have to know how to use configuration management tools, or know almost anything about operating system their software runs on.
What more could you want besides paying 5x more for the privilege ? It's just outsourcing.
Edit: I wanted to add that from what I've seen recently. "Engineers" who aren't familiar with how the various layers of the OSI model work and know a little about operating systems seem to struggle to build useful, secure solutions at higher levels which function at scale. Ultimately, we're still writing code to run on Von Neuman computers.
except its not outsourcing, not really, you still need a strong understanding of what you are doing at all levels, hardware and software for any kind of serious setup.
- managed systems like s3, dynamodb, etc, which are not trivial to run yourself
- on-demand and flexible instance types which allow you to try something without committing
- spot instances, autoscaling groups, access to job scheduling like kubernetes. At scale (thousands of nodes) technologies like this are extremely important
- redundant and reliable service. It also gives you someone to complain too and blame (they provide slas)
- powerful management tooling and APIs that are well documented and widely understood (you can hire an engineer that has used AWS)
- security: audit trails, integrated single sign on, private networks, vpns, role based access keys
I could keep going. Also keep in mind that reserved pricing (or googles sustained use discount) lowers the cost.
> managed systems like s3, dynamodb, etc, which are not trivial to run yourself
How many organisations need a database to scale like that ? Maybe 1000 worldwide, and at least 900 of them are forbidden by law to run them on clouds (e.g. banks).
Also, cloud is essentially outsourcing server management. If you're of a size that needs these sorts of databases, you need a big IT department, cloud or no cloud. At that point, cloud is just vastly more expensive without any monetary advantage.
And of course, if you use any of these, the lock in is ridiculous. Also known as "they have you by the b....", and if one thing is damned sure the result will not be saving money, complexity or effort. Or savings of any kind whatsoever.
> on-demand and flexible instance types which allow you to try something without committing
And ever more management systems that let management "control spending", "control access", ... and so on, designed to prevent that. The problem with the old system was management and processes getting in the way of experimenting, and the only advantage cloud has is that it doesn't have decent support for such processes yet.
Every vendor is racing to build them in, and it's getting worse week by week. It won't be long before experimenting is impossible in cloud just like it is in owned datacenter and dedicated setups.
The problem with experiments is management in every company I've ever consulted for, and cloud doesn't change a thing, aside from, at the moment, management incompetence getting in the way of their usual sabotage. That will stop once current engineers that know cloud start getting a few promos and is already happening.
> spot instances, autoscaling groups, access to job scheduling like kubernetes. At scale (thousands of nodes) technologies like this are extremely important
There is no shortage of system supporting this sort of load on dedicated machines, servers, ...
> redundant and reliable service. It also gives you someone to complain too and blame (they provide slas)
Have you read those slas ? They'll return 10% or so of what you normally pay (not in cash of course, in vouchers) if their service is out for 33% of the time or so. That's not an sla, that's just laughable. If they are out for 5% of the total time, I'd be so pissed I'd start a chargeback.
As for redundancy and reliability, there is no shortage of vendors with similar reliability track records, and it is well documented how to make server setups that provide reliability.
> powerful management tooling and APIs that are well documented and widely understood (you can hire an engineer that has used AWS)
And dedicated servers are linux servers. You can hire engineers, I believe, that have used those.
> security: audit trails, integrated single sign on, private networks, vpns, role based access keys
Yep, these controls are part of what's preventing that experimenting advantage that currently exists. In reality, all of this relies on well designed policies at the customer side, and I've yet to see that done properly for more than a single team in any company.
All of these are of course critically dependent on Google's network, tapped by the NSA as documented in the famous leaked "SSL inserted and removed here" slide, and for numerous privacy breaches, Amazon, famous for "somehow" finding out about how the businesses hosted on their cloud work and taking their customers away (apparently more than 100 court cases against Amazon currently going on), or Microsoft, famous for so many things, including pushing through centralization in Skype for the admitted reason of gaining the ability to spy on their customers. I'm sure their ethics in the cloud hosting department are much better.
And please don't even mention those "encrypted storage" assurances. They're not even worth being called bullshit. If I get to write the code that you use to encrypt/de...
Minor point but aws can be HIPPA complient, if it capable of that, bank software will be perfectly fine for complience. (although incredibly terrible for other reasons but I digress)
For small scale, managed services just makes too much sense. I can have a database with automatic backups, security patching, and failover to another region, within seconds in a click of a button. For less than $1/hr. If you know a sysadmin that can do better for cheaper I'm all ears. The ability to scale to Fortune 100 scale with another click of a button is just a cherry on top.
SLAs are nice PR finger pointing tools. No one cares about the pennies you get back. We broke our SLA because Google broke their SLA is a good enough excuse for most of your clients most of the time. Nobody ever got fired for buying IBM still applies.
Also, once you're massive sized, at least AWS (though I'm sure GCP/Azure too) seems more than happy to negotiate below their listed pricing, especially for hardware.
Security and lock-in are definitely real concerns when considering cloud providers. But let's not pretend cloud providers aren't competitive on price and convenience.
And of course, if you use any of these, the lock in is ridiculous. Also known as "they have you by the b....", and if one thing is damned sure the result will not be saving money, complexity or effort. Or savings of any kind whatsoever.
If you have a simple website and need a key-value store, with a few clicks you can configure a DynamoDB instance -- 50 reads+writes/second will cost around $30/month. Most companies would be hard pressed to set up any open source KV store with 24x7 availability, cross-datacenter replication + backups as well as keeping it patched for less than $360/year.
For a small shop without much (or any) operational support, AWS can save money, complexity and effort.
For a larger company with significant load, then it may be cheaper to host the services they need themselves, but the scalability of Amazon services means that's purely a financial decision, not a technical decision -- by the time you start to outgrow the capacity of amazon hosted services, you're generally past the point where it's worth it to host your own.
And while bare metal may be cheaper, when you own bare metal, you own it 24x7 - you can't scale your infrastructure 3X to handle daytime peak load, or scale it 10X for a day to handle end of quarter processing then scale it back down the next day and stop paying for all of that hardware.
Of course, cloud computing is not a panacea and not a perfect fit for all use cases but there are many use cases where it makes sense and can reduce cost and complexity and make it easier to address scalability and redundancy.
> For a small shop without much (or any) operational support, AWS can save money, complexity and effort.
Small shops, in my experience, have more time and labor available than money.
> by the time you start to outgrow the capacity of amazon hosted services, you're generally past the point where it's worth it to host your own.
That's one of my points. There is no such point. The bigger you become, the more money you'll save by doing it yourself. Read the Dropbox migration story:
Also, if this were true, then why aren't Google, FB, Amazon, Microsoft, Alibaba ... hosting their infrastructure on cloud providers (even their own) ? I assure you at such scales, money becomes a very strong argument. And yet all are choosing to not do this, as far as I'm aware.
The bigger your scale, the stronger the argument becomes to not use cloud.
> And while bare metal may be cheaper, when you own bare metal, you own it 24x7 - you can't scale your infrastructure 3X to handle daytime peak load, or scale it 10X for a day to handle end of quarter processing then scale it back down the next day and stop paying for all of that hardware.
Can I make a slightly sarcastic remark ? This cloud scaling is only useful if your credit card can handle 50x the charges. (there was an article to the tune of "cloud: when will we get to the first $500 page refresh ?", but I can't find it right now).
But perhaps better put, since it's cheaper to own and manage 10x the bare metal capacity than it is to cloud rent 1x that capacity, for any non-trivial amount of capacity, this argument does not mean anything. Add to that that 10x the bare metal capacity has lots of advantages, from technical debt ones, like lower lock-in, to financial ones, you actually own the capital.
I don't understand the argument you're making very much at all. It's not self-consistent. Half of what you say can only apply to super-small companies, and half could only apply to the very very large. And when you're in either argument, you say you agree with my objections to the other part. That not doing cloud is cheaper for very large customers, and that cloud doesn't matter for the very small.
There is a usecase for cloud, but it would never support the cloud providers: if you have a load that suddenly requires 1000x capacity and then doesn't require any capacity for at least a month, then cloud makes sense. So, you're a startup oil driller that needs to crunch through geological survey accoustics, sure, by all means. But if people used cloud only in such cases where it actually makes sense then the companies doing cloud would not be economical ...
> why aren't Google, FB, Amazon, Microsoft, Alibaba ... hosting their infrastructure on cloud
They are... they are literally the cloud(s) and their biggest customer. In fact, they are big enough to offer you their ops and expertise for a small fee over baremetal. Many cloud consumers are literally using up the overhead existing in these businesses' hardware that would otherwise be sitting around.
It can be done cheaper, sure but not without giving up opportunity time and work you may just not want to deal with. I certainly am over having to manage supplier relationships or having to wake someone I don't know or find difficult to converse with to bounce a router or kick a generator.
Small shops, in my experience, have more time and labor available than money
When a developer costs the company $100+/hour, it's hard to justify paying him/her to manage a database when you can pay AWS $50/month to do it.... and AWS will almost always do it better than a developer will do in his/her spare time.
The bigger your scale, the stronger the argument becomes to not use cloud.
Sure, very large companies may find it more cost effective to own their own hardware and datacenters, but there's a huge number of comapnies where self-hosting makes no sense. I know someone at a company that pays nearly $1M/month to AWS -- the company has about 50 developers and 2 ops staff to manage the entire compute infrastructure, their server count varies throughout the day depending on customer demand from around 1000 overnight to 8000 servers during peak daytime usage. Their peak lasts from 6am - 6pm, so most servers would be unused for 12 hours a day. They've got about a petabyte of storage in AWS S3.
But, since you're focused on pricing for bare metal vs AWS, let's look at some pricing that's loosely based on a company I used to work for. (this company took data from customers, ran monthly processing and returned aggregated data to customers,so nearly all bandwidth was inbound)
A Dell R530 with a 20 Thread CPU, 4x16GB RAM and 4TB SSD disk (RAID-1 so 2TB usable) is around $8500, or around $275/month for a 3 year lease. You can rent 1U in a reliable coloc for $200 (including network port + basic firewall services), so you're looking at $575/month.
This is roughly equivalent to 4 m4.xlarge's ($0.086/hour each at 3 year reserved pricing) and 2TB SSD EBS disk ($200/month) or around $450/month. Add in a TB of outbound data for $100, so that's $550/month.
Sounds pretty comparable... oh, but you want redundancy, if your machine (or data center) goes up in flames, you don't want to lose your service, so add in another hardware server + fees, so you're paying over $1000/month.
Depending on your need for redundancy, with Amazon you may be fine with an ASG with health check that restarts your server if it fails. Or you can spread your servers across data centers. Or you keep cold spares in another AZ or region that you launch once a day to sync disks so you're only paying for 5 minutes/day of usage)
So that covers base load. So now, at the end of the month your customers have been sending you data, and they expect you to process it and send aggregated reports back to them within 3 days of the end of the month. You don't have enough spare CPU/memory on your existing servers (even if you use your spare server) to do this month-end processing with existing hardware, so you spin up 4 i3.8xlarge's (32 core, 244GB CPU, 8TB local SSD) at $2.50/hour for 32 hours, or $320 for all 4.
Each of those is bigger than the R530's you're using, but let's say pricing is the same, so you're paying another $1000/month to lease servers you're only using 2 days a month.
And now your service grows and you want to expand capacity. If you own the servers, you need to buy new ones and pay someone to rack and configure them and migrate your applications. While with AWS you just do a quick stop/start and suddenly you're running on a bigger server.
This cloud scaling is only useful if your credit card can handle 50x the charges
If you can't pay for your infrastructure it doesn't matter whether you're on cloud servers or not.
> This is roughly equivalent to 4 m4.xlarge's ($0.086/hour each at 3 year reserved pricing) and 2TB SSD EBS disk ($200/month) or around $450/month. Add in a TB of outbound data for $100, so that's $550/month.
That's, including network bandwidth, 40 euros/month. The commit is one month, not three years. And redundancy is a problem, fair enough. How about we take two in every continent, and still comfortably beat you on price ?
You might say that the cpu is not equivalent, but I'll discuss that below. Everything else is obviously equivalent or better.
At this point you've got WAY more of everything, including reliability, for a significantly lower price. Everything. Network bandwidth, cpu capacity, disk, memory, everything.
And this is metal, not virtualized performance. So aside from many tasks performing better (anything that isn't pure compute, anything that needs to use the network, disk, ... whatever), you're also way safer, you actually get to use the memory ...
4x m4.xlarge will give you, in total 16 "vcpu" on a 2.4 GHz Intel Xeon® E5-2676 v3 (most likely), plus 64 gigs of ram. The i7 runs at 4Ghz, with significantly less cache (takes 3 of them have more cache than 1 Xeon). However, since this isn't virtualized it's going to matter a LOT less.
You see you are trying to compare 2/3 of a single xeon cpu in a quad-xeon server virtualized against 100% of a dual xeon server. Surprise ! The 100% dual xeon is more expensive. In reality that R530 is equivalent to 12 m4.xlarges.
So apples to apples, however, non-cloud is absurdly much cheaper.
And I'm being polite here, not pointing out that 100G of internet bandwidth is nothing, and just how much that Hetzner server includes, or your example hosted R530 (will definitely come with, in the worst case possible, 40T, and if you want better prices than that, feel free to contact me)
> > This cloud scaling is only useful if your credit card can handle 50x the charges
> If you can't pay for your infrastructure it doesn't matter whether you're on cloud servers or not.
True, but every big company got big by producing more value for less money. Not hosting on cloud is going to make the less money part a lot easier.
> and at least 900 of them are forbidden by law to run them on clouds (e.g. banks).
Minor nit: banks are increasingly using cloud computing where they legally can, and that's becoming a lot easier now that regulators are using the cloud as well.
The bigger problem for banks with cloud is cross-border data transfer. Will Luxembourg or Monaco or $country allow banks there to host their computers in a cloud in Frankfurt or Dublin or Amsterdam? Sometimes they do, sometimes they don't, so you always have to have a backup plan.
Kubernetes, along with an architecture informed by the salient points the GP, also provides cloud provider mobility while opening up an on-premise story to match.
As with all dependencies, though, you either manage them or they manage you...
My systems generally wrap their usage of third-party components with internal facades -- an interface that I control that provides a clear contract for replacing the component, generally as part of an AntiCorruption Layer [0]. The more costly the replacement, the more need for abstraction, so I can't imagine why I would treat multi-system communication with Googles or Microsofts cloud-ESB as something less prone to change, replacement, or parallel requirements than whatever PDF-generator we're using this week.
You're completely right, if your workload is even so you can get 15 servers installed and use them all year you're better off using bare metal.
However if you have uneven load - say you're in accounting and you need 5 servers most of the time, but 50 in the runup to year end, you will save money in the cloud rather than having 50 servers requiring power and patching and 45 idle.
There are also other benefits to doing things in the cloud. When you start treating machines as disposable you're forced to automate setup. When you've automated setup you no longer patch machines - you get a new patched base image, run the setup, then simply replace the old machines.
> I don't understand, even after using cloud at work, what those cloud systems provide that can't be done, better, cheaper, and with less relying on a single organisation, on dedicated service providers.
You're pretty much spot on, technically. Anything they can do, you can do better, faster, smarter, more streamlined, etc, outside of some core competencies. It's hard to do BigTable better than Google, and my Paxos is just gonna be worse than what a few decades of 'mission critical' at Microsoft will create.
The reason these are viable in the market, though, isn't technical: it's Time To Market and capital expenditures.
For a SaaS company "The Cloud" is a dead end in the long run because it costs too much, but it's golden in the short term because you throw a few credit card numbers at the issue and you're up and running. You scale, make money, scale more, make more money, and then use your half-decades head start on the competition to bring down your costs. Anything that's not working gets turned off, and you've only lost operating costs without some huge hardware investment.
The commercial cloud is not about running things 24/7 cheaper than your datacenter, the commercial cloud is about letting you pretend you have a datacenter while you get your unicorn to an IPO ;)
For investors, CTOs, CIOs, and CEOs the picture is one of transition, not permanence [0]:
> Even if we believe the world is going gaga for cloud - and I do - there are different flavours of cloud, with SaaS comprising a two-thirds of all public cloud spending, by IDC’s estimates. As for those SaaS vendors, they’re running lots (and lots) of VMware. As one insider at a large SaaS provider shared with me, their model is to run on public cloud when they enter a new region, then switch to private data centre once they hit a revenue threshold ($50m).
I've thought like this for a decade, then the hdd of one of my dedicated server at ovh, on which a side-project with paying users runs, failed. I was confident at the moment: I had backups, I knew the server was provided with raid support, so it was just about replacing the hdd. It took one hour of downtime to replace it, and then I got a message from ovh: "the hdd has been replaced. The server still doesn't boot. Customer has to start the server in rescue mode and fix raid support". Now, I wouldn't mind learning about managing raid, but not while my service is down and I keep answering users mails about it.
I switched to aws, despite the additional cost, because it's less dangerous for a small team (or one person team, like me). I realized the additional cost was actually paying for additional services (managing everything related to hardware).
For the majority of use cases, involving relatively static workloads, the cloud doesn't offer many financial benefits, as you say, particularly if you have access to a competent infrastructure engineer (which are harder to find than you'd think).
My experience of cloud has generally been around gambling websites, which have a very distinctive use case pattern, with daily peaks and troughs as well as seasonal peaks and troughs. There can be as much as a 25x difference in throughput between these occasions.
For these sites it's a case of implement scaling natively in the cloud and stop worrying about capacity forecasting or invest millions in infrastructure upfront and watch it idle 90% of the time.
The financials simply work in this field, as I'd guess they do in serious online retailers with seasonal demand. However your average 2 web server, load balancer and single db server, not so much.
In my companies where we used the cloud it just came down to internal pragmatism on our part. If we wanted to hire someone that could take over a year between convincing management to allocate the budget for it and going through HR's hiring process. The cloud was something where the recurring monthly costs were small enough to be expensed. We were given a single IT contractor who worked at multiple sites for the company and would show up 1-2 weeks after you notified him of an issue.
So we ended up using the cloud, the company has a giant liability now that everything is dependent on the cloud providers, but management ends up happy because they only see 4-5figure charges per month and not a 6 figure cost per year they'd see for a new employee. I'm pretty sure if the company's budgets reported employees as monthly costs we could have just gotten another employee, but there's not much you can do when the decisions are made that far above your head
Just as with anything it's evaluated on a case-by-case basis. Serverless is GREAT at starting something, testing it and then evaluating if it's even worth spending time to work on actual server-based stuff. You can get stuff going immediately with little effort without the overhead of setting up a box, managing deps and all the nuances that come up standing up classic servers (even in the cloud). Is it a silver bullet? No, though I'd say it might be for fleshing out ideas.
It's interesting, because as the Serverless space evolves there are two emerging sales and marketing tracks for the technology:
(A) This will reduce your costs (CIO Track)
(B) This will reduce your time to market (PM / Developer Track)
Amiram's article here clearly tries to deconstruct the argument in (A) and suggest, well, it's more expensive than you think (and Spotinst is the cheapest option - kudos to Amiram and team) which... is undeniably true, and API Gateway is a large part of that. It seems based on Re:invent 2017 in November that Amazon is moving to target the (B) track more aggressively, which is where we've been residing in a niche with StdLib since we launched [0].
Realistically I think both tracks are actually half-truths (as is all marketing), as Amiram even touches on re: lines of code written to maintain Serverless architecture. At the end of the day, Serverless technology is going to open up a world Simon Wardley [1] has painted a picture of: one of reliable, fault-tolerant, self-healing, predictably priced service composition that can be performed by developers who are increasingly unaware of implementation details, and perhaps not even developers in the traditional sense.
It's been a neat exercise at StdLib trying to find the intersection between current development paradigms (old hat monoliths, etc.), the utility / lower cost / lower time to delivery of serverless tech, and the future of emergent, unexplored markets. As the marketing sizzle of "serverless" begins to fade (it hasn't peaked yet, but it will), and we see more challenges to the technology itself, it will be interesting to see what business practices and development paradigms pop up around serverless architectures, and how companies begin maximizing the utility of a new development canvas.
One day it won't be "serverless," it will simply be best practice for most companies to ship application logic directly to the runtime layer. What does that world look like, where will costs (/prices) settle, and how do all players in the market continue delivering the most value to developers and companies? It'll be neat to watch it all play out, to say the least.
There's an interesting side effect I've seen that a serverless approach enables, which is that it is now much easier to logically separate your various routes and logic to "route handlers" or "services".
However, if you naturally extend your system with these logically separated handlers in a vacuum, which is easy to do, and you have not thought through your packaging and dependency management, you can quickly fall into a pattern of producing a lot of duplicate boilerplate and utility functionality that a monolith would have avoided. Basically, take all the pain points and downsides of SOA and make it really easy to make all the mistakes.
That said, when approached with foresight, it's a perfectly manageable problem and I wouldn't agree that it is linear.
I don't buy the author's conclusion. I've deployed both Python and Node.js projects to AWS Lambda. I used Zappa (https://www.zappa.io/) and Claudia.js (https://claudiajs.com/) to deploy them, and only added minimal configuration to my codebase. If LOC is growing in the manner described, something is very wrong with the team's methods of configuration/deployment.
I think serverless basically just means sharing more with other customers. You don't juts share the same hardware running your own VM on it, you share the same VM executing a big program one part of which is your lambda-functions. This leads to better utilization of hardware resources.
It's not about a cloud vs. inhouse you might have the lambdas of your different departments running in the same VM.
API gateway costs on AWS seems like a massive "gotcha", especially considering how access via HTTP is super important for those worried about vendor lock in.
This article was written by someone with a competing service, but I know there are a bunch of projects right now (including mine) that come out of the box with HTTPS, run generic/vendor-agnostic containers, and can even be self hosted.
Self hosted seems to offer the best of both worlds; FAAS with fine grained control over platform costs, at the cost of the devops work to setup and maintain.
110 comments
[ 3.3 ms ] story [ 190 ms ] threadSpeaking as a fan of AWS: neither of those is in any way inevitable.
https://aws.amazon.com/blogs/aws/in-the-works-amazon-aurora-...
The problem on Lambda is that you can’t persist any application state beyond the function call itself, so you can’t take advantage of connection pooling the way you normally would in a self-contained webapp. Without some kind of middleman, each database call will require you to open a new connection to the database and close it when the function ends. This becomes catastrophic for the database server as the number of requests scales up.
Example: https://docs.aws.amazon.com/lambda/latest/dg/vpc-rds-deploym...
it would save everyone a lot of time and energy to not have to deal with server instances, so its likely a better model will come along. persistent storage in the presence of scaling and concurrency is a bit of thorn though.
If you're using Terraform + modern config management tools I find it a breeze. I feel like this is a weak argument.
If developers are unable to understand how something like Salt, Chef or Ansible works then I'd be surprised.
I guess it mostly stings when there is a critical openssl update, or something analogous. Despite the ideal of continuous integration and lightweight deployment - none of the shops I've worked at lately can make than happen in the 10 minutes its supposed to take.
Writing a back-end for a mobile app right now. I need a few CRUD calls, but I also need stuff to stay in real-time sync between users.
So far I've been able to sprinkle magic cloud fairy dust on things, solve auth, solve concurrency, and deployment is super easy.
I originally thought about doing it on a VPS. Then I realized I'd have to deal with a bunch of issues that I Just Don't Want To Deal With Right Now, especially since I am trying to get an MVP out ASAP to validate my idea. The various cloud providers all offer nice, well tested, SDKs to do all of the nasty/boring work for me, and a single call on my command line deploys everything.
IMHO neither moving to the cloud or serverless entirely are inevitable unless you have unlimited resources and don’t mind contributing to Amazon’s margins, but both have their places when time is more valuable than infrastructure (although as you require additional capacity, it’s time to refactor your use of infrastructure moving down the abstraction layers).
Disclaimer: my org has and intends to keep quite a bit of hardware on prem at our own datacenters, but also spends mid six figures on AWS monthly
To me it sounds like this whole "serverless revolution" is just the product of Amazon's PR team who found a nice term to befuddle and bedazzle know-nothing CEOs.
Serverless may be a disingenuous term, but it does refer to a useful thing.
Regardless it's still not server-less... The entire system is still running off a server...
So server-less is a misnomer.
Cold starts as an issue? I mean, all you have to do is create a CloudWatch event (or cron if you want an explicit server involved) to fire the Lambda function every few minutes and you're all good. Sure, if you get heavy traffic, I suppose you could have multiple containers running simultaneously? But that's also easy enough to handle w/ CW events.
My mobile client's edit doesn't work
Decentralized solutions 100% definitely absolutely do not.
I don't have any problem with "serverless". Years ago I wrote a nginx handler that routed to .py files and ran them inside an lxc container, while at a hosting company. Fronted via haproxy, and documented with sphinx automatically.
My problem is the hidden costs. Sure lambda requests are low cost. But what about API gateway, dynamo/rds access. Then I'm writing a basic crud app. Low-performance low request rate, noncritical. There is this additional complexity, that just isn't necessary. Every day at my job I'm thinking to myself it doesn't need to be this difficult.
My usual route is django, django admin, and django rest. With an haproxy in front for load balancing. Dead simple and easy to work with. It's passe sure, but KISS. The alternative here is an api and a frontend. Several more projects to maintain. Tuning the projects to meet lambda size requirements/standards. The return on investment is minimal to me. If you can't automate managing a fleet of containers or vps instances then why're you here?
The vendor lock-in, is insane to me. You're pretty much at the beck and whim of the provider. They raise the prices, what're you going to do. You either go with the price increase or do a rewrite.
As I was sitting in these architecture meetings on moving too lambda. I was hearing several new packages/repos. New CI/CD, and configuration to maintain. During the meeting I scratched out a POC using EC2, Load Balancer, RDS and django to do what they were saying with half the code. But nope gotta be lambda.
In the 11 year history of AWS, I don't think they've ever increased prices for anything. I'm pretty comfortable with their ability to avoid it in the future.
So you can build a globally distributed, redundant, eventually consistent object store with high availability easily and conveniently and without allocating developer time that could be better used building..oh I don't know, the actual business logic? Not to mention ongoing maintenance and its expense.
It's ridiculous to suggest that the entirety of the AWS offering is something that is just slightly more convenient than what could be built in house.
The ease through which Amazon provides the ability to architect incredibly globally redundant applications is unmatched. But your business probably can’t afford to implement at that scale, Amazon or otherwise (geographically load balanced DNS, multiple primary databases across regions and their associated followers, replicating S3 objects from all primary region buckets to secondary regions, instances for each application running multi-AZ in multiple regions, etc).
https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html
> Cross-region replication is a bucket-level configuration that enables automatic, asynchronous copying of objects across buckets in different AWS Regions. We refer to these buckets as source bucket and destination bucket. These buckets can be owned by different AWS accounts.
Most of HN is thinly veiled marketing supporting special interests. I think a huge part of the value of HN is lowering the barrier to entry to build great companies by providing a platform to announce and promote your product / team / etc. as well as educate people with quality content. We celebrate "Launch HN" and funding events, and are going to criticize a founder for building something awesome and talking about it? That seems a bit silly to me.
> The article is basically marketing copy devoid of technical details.
So since you agree with OP that it's marketing, _perhaps_ it's not a stretch to suggest that it's a bit shady for the CEO of Super Cheap Cloud Product to author a marketing piece decrying the hidden costs of OMG So Expensive Cloud Products as though it's just helpful advice?
> I think a huge part of the value of HN is lowering the barrier to entry to build great companies by providing a platform to announce and promote your product / team / etc. as well as educate people with quality content. We celebrate "Launch HN" and funding events, and are going to criticize a founder for building something awesome and talking about it?
Apples and oranges. There's a big difference between "check out this thing I made" and "these products all have somewhat opaque problems _by the way I'm CEO of a competitor_".
If you don't agree with the article, that's one thing. Can you pick out anything in the post that's counterfactual? Look - I'm the CEO of a cloud product that, in some sense, could be considered competitive with Amiram. I've made plenty of upvoted HN comments and Medium posts talking directly about our company and what we do - hell, there's one posted here if you scroll down. I take a great deal of pride in it, and I'm very enthusiastic about the future of the space. It's for that reason I consider the criticism a little unfair.
If the criticism is simply, "be more direct with your marketing and assert yourself and your company" --- that's totally fine. But dismissing an entire article because it's actively providing advice and context because the CEO runs a company in the space (wouldn't that put him in the best position to understand the market?) is... well, like I said, kind of silly.
If the above is, in fact, the actual criticism - perhaps we should ask A Cloud Guru if they'd be more willing to allow promotional posts to feature partners and neat products. A big problem with content marketing (generally) is the people who control the flow of content often ask for pieces to appear as neutral as possible, where a huge chunk of motivated content producers are actually trying to push a product or service (platform, consultancy, themselves and their career, their open source, you name it).
Having run content marketing, I can say that it helps reader substantially to know an article is written by an interested party.
For example, if I were an expert in a field with two options A and B, and I ran a company that did only A, I would be tempted to release true facts that support A only. None of the facts released A would be wrong -- all would be correct. I could say "find a flaw with any of those arguments" -- and none can be found!
But if a reader were to infer that A is much better when she reads true facts selectively released to support, she would be substantially wrong. Moreover, she would be able to deduce that if she knew I were rooting for team A. This is why being so hidden about your position is shady.
I agree that the facts, when collected from many sources, help the reader a lot. But if the goal is to get the reader to make the right decision, the marginal article with "selective true facts" can be a curse rather than a blessing.
Maybe the article has been edited since it posted here, but I don't see any reference to Spotinst product pricing. I only see IBM, Amazon, Azure and Google services in those tables.
You may not have found the article useful, but as a "serverless" noob, I found it worthwhile. It certainly wasn't "devoid" of technical details.
Since VPS's exist cloud doesn't even make sense for the smallest websites anymore. Ironically VPS's predate and are even the basis of cloud systems.
And there's the intangible technical debt that cloud imparts. Whichever cloud you pick, in the future you'll change. That's how the world works. Switching dedicated service providers is a complicated ops problem. Switching cloud providers is a full rewrite of everything AND a complicated ops problem. Just being on the cloud, by itself, forces you to put in serious technical debt.
I don't understand, even after using cloud at work, what those cloud systems provide that can't be done, better, cheaper, and with less relying on a single organisation, on dedicated service providers.
I mean Google's hypervisor is good (very good), but it still imparts significant costs compared to bare metal.
What more could you want besides paying 5x more for the privilege ? It's just outsourcing.
Edit: I wanted to add that from what I've seen recently. "Engineers" who aren't familiar with how the various layers of the OSI model work and know a little about operating systems seem to struggle to build useful, secure solutions at higher levels which function at scale. Ultimately, we're still writing code to run on Von Neuman computers.
I agree with you, but what's the incentive to learn that stuff these days?
I mean I know its not a concern for startups fueled by some one else's money, but it still matters.
- managed systems like s3, dynamodb, etc, which are not trivial to run yourself
- on-demand and flexible instance types which allow you to try something without committing
- spot instances, autoscaling groups, access to job scheduling like kubernetes. At scale (thousands of nodes) technologies like this are extremely important
- redundant and reliable service. It also gives you someone to complain too and blame (they provide slas)
- powerful management tooling and APIs that are well documented and widely understood (you can hire an engineer that has used AWS)
- security: audit trails, integrated single sign on, private networks, vpns, role based access keys
I could keep going. Also keep in mind that reserved pricing (or googles sustained use discount) lowers the cost.
How many organisations need a database to scale like that ? Maybe 1000 worldwide, and at least 900 of them are forbidden by law to run them on clouds (e.g. banks).
Also, cloud is essentially outsourcing server management. If you're of a size that needs these sorts of databases, you need a big IT department, cloud or no cloud. At that point, cloud is just vastly more expensive without any monetary advantage.
And of course, if you use any of these, the lock in is ridiculous. Also known as "they have you by the b....", and if one thing is damned sure the result will not be saving money, complexity or effort. Or savings of any kind whatsoever.
> on-demand and flexible instance types which allow you to try something without committing
And ever more management systems that let management "control spending", "control access", ... and so on, designed to prevent that. The problem with the old system was management and processes getting in the way of experimenting, and the only advantage cloud has is that it doesn't have decent support for such processes yet.
Every vendor is racing to build them in, and it's getting worse week by week. It won't be long before experimenting is impossible in cloud just like it is in owned datacenter and dedicated setups.
The problem with experiments is management in every company I've ever consulted for, and cloud doesn't change a thing, aside from, at the moment, management incompetence getting in the way of their usual sabotage. That will stop once current engineers that know cloud start getting a few promos and is already happening.
> spot instances, autoscaling groups, access to job scheduling like kubernetes. At scale (thousands of nodes) technologies like this are extremely important
There is no shortage of system supporting this sort of load on dedicated machines, servers, ...
> redundant and reliable service. It also gives you someone to complain too and blame (they provide slas)
Have you read those slas ? They'll return 10% or so of what you normally pay (not in cash of course, in vouchers) if their service is out for 33% of the time or so. That's not an sla, that's just laughable. If they are out for 5% of the total time, I'd be so pissed I'd start a chargeback.
As for redundancy and reliability, there is no shortage of vendors with similar reliability track records, and it is well documented how to make server setups that provide reliability.
> powerful management tooling and APIs that are well documented and widely understood (you can hire an engineer that has used AWS)
And dedicated servers are linux servers. You can hire engineers, I believe, that have used those.
> security: audit trails, integrated single sign on, private networks, vpns, role based access keys
Yep, these controls are part of what's preventing that experimenting advantage that currently exists. In reality, all of this relies on well designed policies at the customer side, and I've yet to see that done properly for more than a single team in any company.
All of these are of course critically dependent on Google's network, tapped by the NSA as documented in the famous leaked "SSL inserted and removed here" slide, and for numerous privacy breaches, Amazon, famous for "somehow" finding out about how the businesses hosted on their cloud work and taking their customers away (apparently more than 100 court cases against Amazon currently going on), or Microsoft, famous for so many things, including pushing through centralization in Skype for the admitted reason of gaining the ability to spy on their customers. I'm sure their ethics in the cloud hosting department are much better.
And please don't even mention those "encrypted storage" assurances. They're not even worth being called bullshit. If I get to write the code that you use to encrypt/de...
https://aws.amazon.com/solutions/case-studies/capital-one/
https://www.computerworld.com/article/3145622/cloud-computin...
And they are even investing in cloud companies:
https://www.geekwire.com/2017/trying-snowflake-computings-ne...
SLAs are nice PR finger pointing tools. No one cares about the pennies you get back. We broke our SLA because Google broke their SLA is a good enough excuse for most of your clients most of the time. Nobody ever got fired for buying IBM still applies.
Also, once you're massive sized, at least AWS (though I'm sure GCP/Azure too) seems more than happy to negotiate below their listed pricing, especially for hardware.
Security and lock-in are definitely real concerns when considering cloud providers. But let's not pretend cloud providers aren't competitive on price and convenience.
If you have a simple website and need a key-value store, with a few clicks you can configure a DynamoDB instance -- 50 reads+writes/second will cost around $30/month. Most companies would be hard pressed to set up any open source KV store with 24x7 availability, cross-datacenter replication + backups as well as keeping it patched for less than $360/year.
For a small shop without much (or any) operational support, AWS can save money, complexity and effort.
For a larger company with significant load, then it may be cheaper to host the services they need themselves, but the scalability of Amazon services means that's purely a financial decision, not a technical decision -- by the time you start to outgrow the capacity of amazon hosted services, you're generally past the point where it's worth it to host your own.
And while bare metal may be cheaper, when you own bare metal, you own it 24x7 - you can't scale your infrastructure 3X to handle daytime peak load, or scale it 10X for a day to handle end of quarter processing then scale it back down the next day and stop paying for all of that hardware.
Of course, cloud computing is not a panacea and not a perfect fit for all use cases but there are many use cases where it makes sense and can reduce cost and complexity and make it easier to address scalability and redundancy.
Small shops, in my experience, have more time and labor available than money.
> by the time you start to outgrow the capacity of amazon hosted services, you're generally past the point where it's worth it to host your own.
That's one of my points. There is no such point. The bigger you become, the more money you'll save by doing it yourself. Read the Dropbox migration story:
https://blogs.dropbox.com/tech/2016/03/magic-pocket-infrastr...
Also, if this were true, then why aren't Google, FB, Amazon, Microsoft, Alibaba ... hosting their infrastructure on cloud providers (even their own) ? I assure you at such scales, money becomes a very strong argument. And yet all are choosing to not do this, as far as I'm aware.
The bigger your scale, the stronger the argument becomes to not use cloud.
> And while bare metal may be cheaper, when you own bare metal, you own it 24x7 - you can't scale your infrastructure 3X to handle daytime peak load, or scale it 10X for a day to handle end of quarter processing then scale it back down the next day and stop paying for all of that hardware.
Can I make a slightly sarcastic remark ? This cloud scaling is only useful if your credit card can handle 50x the charges. (there was an article to the tune of "cloud: when will we get to the first $500 page refresh ?", but I can't find it right now).
But perhaps better put, since it's cheaper to own and manage 10x the bare metal capacity than it is to cloud rent 1x that capacity, for any non-trivial amount of capacity, this argument does not mean anything. Add to that that 10x the bare metal capacity has lots of advantages, from technical debt ones, like lower lock-in, to financial ones, you actually own the capital.
I don't understand the argument you're making very much at all. It's not self-consistent. Half of what you say can only apply to super-small companies, and half could only apply to the very very large. And when you're in either argument, you say you agree with my objections to the other part. That not doing cloud is cheaper for very large customers, and that cloud doesn't matter for the very small.
There is a usecase for cloud, but it would never support the cloud providers: if you have a load that suddenly requires 1000x capacity and then doesn't require any capacity for at least a month, then cloud makes sense. So, you're a startup oil driller that needs to crunch through geological survey accoustics, sure, by all means. But if people used cloud only in such cases where it actually makes sense then the companies doing cloud would not be economical ...
They are... they are literally the cloud(s) and their biggest customer. In fact, they are big enough to offer you their ops and expertise for a small fee over baremetal. Many cloud consumers are literally using up the overhead existing in these businesses' hardware that would otherwise be sitting around.
It can be done cheaper, sure but not without giving up opportunity time and work you may just not want to deal with. I certainly am over having to manage supplier relationships or having to wake someone I don't know or find difficult to converse with to bounce a router or kick a generator.
When a developer costs the company $100+/hour, it's hard to justify paying him/her to manage a database when you can pay AWS $50/month to do it.... and AWS will almost always do it better than a developer will do in his/her spare time.
The bigger your scale, the stronger the argument becomes to not use cloud.
Sure, very large companies may find it more cost effective to own their own hardware and datacenters, but there's a huge number of comapnies where self-hosting makes no sense. I know someone at a company that pays nearly $1M/month to AWS -- the company has about 50 developers and 2 ops staff to manage the entire compute infrastructure, their server count varies throughout the day depending on customer demand from around 1000 overnight to 8000 servers during peak daytime usage. Their peak lasts from 6am - 6pm, so most servers would be unused for 12 hours a day. They've got about a petabyte of storage in AWS S3.
But, since you're focused on pricing for bare metal vs AWS, let's look at some pricing that's loosely based on a company I used to work for. (this company took data from customers, ran monthly processing and returned aggregated data to customers,so nearly all bandwidth was inbound)
A Dell R530 with a 20 Thread CPU, 4x16GB RAM and 4TB SSD disk (RAID-1 so 2TB usable) is around $8500, or around $275/month for a 3 year lease. You can rent 1U in a reliable coloc for $200 (including network port + basic firewall services), so you're looking at $575/month.
This is roughly equivalent to 4 m4.xlarge's ($0.086/hour each at 3 year reserved pricing) and 2TB SSD EBS disk ($200/month) or around $450/month. Add in a TB of outbound data for $100, so that's $550/month.
Sounds pretty comparable... oh, but you want redundancy, if your machine (or data center) goes up in flames, you don't want to lose your service, so add in another hardware server + fees, so you're paying over $1000/month.
Depending on your need for redundancy, with Amazon you may be fine with an ASG with health check that restarts your server if it fails. Or you can spread your servers across data centers. Or you keep cold spares in another AZ or region that you launch once a day to sync disks so you're only paying for 5 minutes/day of usage)
So that covers base load. So now, at the end of the month your customers have been sending you data, and they expect you to process it and send aggregated reports back to them within 3 days of the end of the month. You don't have enough spare CPU/memory on your existing servers (even if you use your spare server) to do this month-end processing with existing hardware, so you spin up 4 i3.8xlarge's (32 core, 244GB CPU, 8TB local SSD) at $2.50/hour for 32 hours, or $320 for all 4.
Each of those is bigger than the R530's you're using, but let's say pricing is the same, so you're paying another $1000/month to lease servers you're only using 2 days a month.
And now your service grows and you want to expand capacity. If you own the servers, you need to buy new ones and pay someone to rack and configure them and migrate your applications. While with AWS you just do a quick stop/start and suddenly you're running on a bigger server.
This cloud scaling is only useful if your credit card can handle 50x the charges
If you can't pay for your infrastructure it doesn't matter whether you're on cloud servers or not.
How about this one ?
https://www.hetzner.com/dedicated-rootserver/ex41s
That's, including network bandwidth, 40 euros/month. The commit is one month, not three years. And redundancy is a problem, fair enough. How about we take two in every continent, and still comfortably beat you on price ?
You might say that the cpu is not equivalent, but I'll discuss that below. Everything else is obviously equivalent or better.
At this point you've got WAY more of everything, including reliability, for a significantly lower price. Everything. Network bandwidth, cpu capacity, disk, memory, everything.
And this is metal, not virtualized performance. So aside from many tasks performing better (anything that isn't pure compute, anything that needs to use the network, disk, ... whatever), you're also way safer, you actually get to use the memory ...
4x m4.xlarge will give you, in total 16 "vcpu" on a 2.4 GHz Intel Xeon® E5-2676 v3 (most likely), plus 64 gigs of ram. The i7 runs at 4Ghz, with significantly less cache (takes 3 of them have more cache than 1 Xeon). However, since this isn't virtualized it's going to matter a LOT less.
You see you are trying to compare 2/3 of a single xeon cpu in a quad-xeon server virtualized against 100% of a dual xeon server. Surprise ! The 100% dual xeon is more expensive. In reality that R530 is equivalent to 12 m4.xlarges.
So apples to apples, however, non-cloud is absurdly much cheaper.
And I'm being polite here, not pointing out that 100G of internet bandwidth is nothing, and just how much that Hetzner server includes, or your example hosted R530 (will definitely come with, in the worst case possible, 40T, and if you want better prices than that, feel free to contact me)
> > This cloud scaling is only useful if your credit card can handle 50x the charges
> If you can't pay for your infrastructure it doesn't matter whether you're on cloud servers or not.
True, but every big company got big by producing more value for less money. Not hosting on cloud is going to make the less money part a lot easier.
Minor nit: banks are increasingly using cloud computing where they legally can, and that's becoming a lot easier now that regulators are using the cloud as well.
The bigger problem for banks with cloud is cross-border data transfer. Will Luxembourg or Monaco or $country allow banks there to host their computers in a cloud in Frankfurt or Dublin or Amsterdam? Sometimes they do, sometimes they don't, so you always have to have a backup plan.
> And dedicated servers are linux servers. You can hire engineers, I believe, that have used those.
Hiring a single engineer to do this is more expensive than using a cloud service...
As with all dependencies, though, you either manage them or they manage you...
My systems generally wrap their usage of third-party components with internal facades -- an interface that I control that provides a clear contract for replacing the component, generally as part of an AntiCorruption Layer [0]. The more costly the replacement, the more need for abstraction, so I can't imagine why I would treat multi-system communication with Googles or Microsofts cloud-ESB as something less prone to change, replacement, or parallel requirements than whatever PDF-generator we're using this week.
-
[0] - http://www.markhneedham.com/blog/2009/07/07/domain-driven-de...
However if you have uneven load - say you're in accounting and you need 5 servers most of the time, but 50 in the runup to year end, you will save money in the cloud rather than having 50 servers requiring power and patching and 45 idle.
There are also other benefits to doing things in the cloud. When you start treating machines as disposable you're forced to automate setup. When you've automated setup you no longer patch machines - you get a new patched base image, run the setup, then simply replace the old machines.
You're pretty much spot on, technically. Anything they can do, you can do better, faster, smarter, more streamlined, etc, outside of some core competencies. It's hard to do BigTable better than Google, and my Paxos is just gonna be worse than what a few decades of 'mission critical' at Microsoft will create.
The reason these are viable in the market, though, isn't technical: it's Time To Market and capital expenditures.
For a SaaS company "The Cloud" is a dead end in the long run because it costs too much, but it's golden in the short term because you throw a few credit card numbers at the issue and you're up and running. You scale, make money, scale more, make more money, and then use your half-decades head start on the competition to bring down your costs. Anything that's not working gets turned off, and you've only lost operating costs without some huge hardware investment.
The commercial cloud is not about running things 24/7 cheaper than your datacenter, the commercial cloud is about letting you pretend you have a datacenter while you get your unicorn to an IPO ;)
For investors, CTOs, CIOs, and CEOs the picture is one of transition, not permanence [0]:
> Even if we believe the world is going gaga for cloud - and I do - there are different flavours of cloud, with SaaS comprising a two-thirds of all public cloud spending, by IDC’s estimates. As for those SaaS vendors, they’re running lots (and lots) of VMware. As one insider at a large SaaS provider shared with me, their model is to run on public cloud when they enter a new region, then switch to private data centre once they hit a revenue threshold ($50m).
-
[0] - https://www.theregister.co.uk/2017/09/11/kubernetes_envy/
I switched to aws, despite the additional cost, because it's less dangerous for a small team (or one person team, like me). I realized the additional cost was actually paying for additional services (managing everything related to hardware).
My experience of cloud has generally been around gambling websites, which have a very distinctive use case pattern, with daily peaks and troughs as well as seasonal peaks and troughs. There can be as much as a 25x difference in throughput between these occasions. For these sites it's a case of implement scaling natively in the cloud and stop worrying about capacity forecasting or invest millions in infrastructure upfront and watch it idle 90% of the time.
The financials simply work in this field, as I'd guess they do in serious online retailers with seasonal demand. However your average 2 web server, load balancer and single db server, not so much.
So we ended up using the cloud, the company has a giant liability now that everything is dependent on the cloud providers, but management ends up happy because they only see 4-5figure charges per month and not a 6 figure cost per year they'd see for a new employee. I'm pretty sure if the company's budgets reported employees as monthly costs we could have just gotten another employee, but there's not much you can do when the decisions are made that far above your head
(A) This will reduce your costs (CIO Track)
(B) This will reduce your time to market (PM / Developer Track)
Amiram's article here clearly tries to deconstruct the argument in (A) and suggest, well, it's more expensive than you think (and Spotinst is the cheapest option - kudos to Amiram and team) which... is undeniably true, and API Gateway is a large part of that. It seems based on Re:invent 2017 in November that Amazon is moving to target the (B) track more aggressively, which is where we've been residing in a niche with StdLib since we launched [0].
Realistically I think both tracks are actually half-truths (as is all marketing), as Amiram even touches on re: lines of code written to maintain Serverless architecture. At the end of the day, Serverless technology is going to open up a world Simon Wardley [1] has painted a picture of: one of reliable, fault-tolerant, self-healing, predictably priced service composition that can be performed by developers who are increasingly unaware of implementation details, and perhaps not even developers in the traditional sense.
It's been a neat exercise at StdLib trying to find the intersection between current development paradigms (old hat monoliths, etc.), the utility / lower cost / lower time to delivery of serverless tech, and the future of emergent, unexplored markets. As the marketing sizzle of "serverless" begins to fade (it hasn't peaked yet, but it will), and we see more challenges to the technology itself, it will be interesting to see what business practices and development paradigms pop up around serverless architectures, and how companies begin maximizing the utility of a new development canvas.
One day it won't be "serverless," it will simply be best practice for most companies to ship application logic directly to the runtime layer. What does that world look like, where will costs (/prices) settle, and how do all players in the market continue delivering the most value to developers and companies? It'll be neat to watch it all play out, to say the least.
[0] https://stdlib.com/
[1] http://blog.gardeviance.org/2016/11/why-fuss-about-serverles...
However, if you naturally extend your system with these logically separated handlers in a vacuum, which is easy to do, and you have not thought through your packaging and dependency management, you can quickly fall into a pattern of producing a lot of duplicate boilerplate and utility functionality that a monolith would have avoided. Basically, take all the pain points and downsides of SOA and make it really easy to make all the mistakes.
That said, when approached with foresight, it's a perfectly manageable problem and I wouldn't agree that it is linear.
What a dangerous thought.
It's not about a cloud vs. inhouse you might have the lambdas of your different departments running in the same VM.
"serverless" really means "shared program".
This article was written by someone with a competing service, but I know there are a bunch of projects right now (including mine) that come out of the box with HTTPS, run generic/vendor-agnostic containers, and can even be self hosted.
Self hosted seems to offer the best of both worlds; FAAS with fine grained control over platform costs, at the cost of the devops work to setup and maintain.