The hidden costs of serverless
read.acloud.guru
read.acloud.guru
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/decrypt, I can obviously trivially break any key you use. If you don't believe me, I'll give you a webbrowser to download, and I assure you it encrypts all your passwords, then just log into your web banking a few times and see what happens (note: webbrowsers inserting "extra" transactions when doing webbanking are a common thing to find in security work).
So secure ... yeah right.
Sure, it can work. It won't, of course.
> I could keep going.
Yeah you could mention that cloud's real advantage is that engineers believe that if they get a web-based non-multiplayer version of minesweeper implemented on kubernetes, they'll get a $200k+ GOOG/FB job. Not true, of course, but nobody wants to tell em that. In fact, implementing a linked list in C on a DOS 1.0 C compiler will help them a LOT more.
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
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.
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.
(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.
[1] http://blog.gardeviance.org/2016/11/why-fuss-about-serverles...
Speaking as a fan of AWS: neither of those is in any way inevitable.
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
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".
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...
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.
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.
Regardless it's still not server-less... The entire system is still running off a server...
So server-less is a misnomer.
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.