My word. I'm sort of gob smacked this article exists.
I know there are nuances in the article, but my first impression was it's saying "we went back to basics and stopped using needless expensive AWS stuff that caused us to completely over architect our application and the results were much better". Which is good lesson, and a good story, but there's a kind of irony it's come from an internal Amazon team. As another poster commented, I wouldn't be surprised if it's taken down at some point.
There was an article not long ago from AWS saying they'll be focussing on cutting cost for customers. Maybe the next step of that process will be pushing their clients off of AWS and telling them to just host on prem.
I know you're joking around, but no, as they also explained a benefit of cloud (and therefore using AWS) is that it can scale flexibly with their customers' businesses.
If your business invests in physical servers anticipating strong growth next year then later finds out actually we're going into a recession and those servers are no longer needed, then that's a sunk cost.
With cloud if demand drops you can scale up and down as needed. Helping customers cut costs during difficult times makes sense since those customers are more likely to survive and stay with you through good times.
So in context I think this article makes sense since long-term sustainable growth of AWS should be linked with the growth of their customers' businesses.
> If your business invests in physical servers anticipating strong growth next year then later finds out actually we're going into a recession and those servers are no longer needed, then that's a sunk cost.
Cloud vendors also mostly sell minimum use packages for discounts in the range of 20 to 80% (called e.g. "committed use discount" or "compute savings plan"). Lots of businesses use those, because two-digit discounts are real money, but they might find themselves in the same spot as with physical hardware they don't need...
I'm a cloud proponent because it means not having to sit through hours of meetings to deploy a $5/mo virtual machine.
It also means some poor fuck at AWS gets woken up in the middle of the night instead of me when things go to shit.
It absolutely comes at a cost, and might not be the right fit for an organisation that's absolutely on top of it's hardware requirements and can afford to divert resources from new development work. For the rest of us it saves a lot of dev hours that would have otherwise been spent in pointless meetings or debating the best implementation of whatever half-baked stack has oozed it's way out of the organisation in an attempt to replicate what's handed to you with a cloud solution.
> I'm a cloud proponent because it means not having to sit through hours of meetings to deploy a $5/mo virtual machine.
And endless orgies of "call for pricing" with hardware vendors and hosting. Shitty websites where you can buy preconfigured servers somewhat cheaply, or vendor websites where you can configure everything but overpay. Useless sales-droids trying to "value-add" stuff on top.
Cloud buys are a lot friendlier, because you only have the one cloud vendor to worry about. Entry level you just pay list price by clicking a button. If you buy a lot, you are big enough to have your own business people to hammer out a rebate on list price, still very easy, still very simple. But overall still more expensive unfortunately.
> I'm a cloud proponent because it means not having to sit through hours of meetings to deploy a $5/mo virtual machine.
I'd hope there aren't actually hours of meetings for a single $5/mo VM?
But I would hope there are reviews and meetings when deploying enough of these to amount to real money. Companies that don't do that soon enough find themselves with a million dollar AWS bill without understanding what's going on.
Spend is spend, it's vital to understand what is being spent on what and why.
> I'd hope there aren't actually hours of meetings for a single $5/mo VM?
Slightly exaggerated in the case of the $5 machine, probably 2-3 manhours total but it took 4 days for it to be deployed instead of ~5 minutes. We did spent tens of hours justifying why the business should spend ~$100 more per month on a production system where the metrics clearly indicated that it was resource constrained.
The same IT department that demanded we justify every penny spent did not apply any of that rigour to their own spending. Control over the deployment of resources was used as a political tool to increase their headcount.
> I would hope there are reviews and meetings when deploying enough of these to amount to real money. Companies that don't do that soon enough find themselves with a million dollar AWS bill without understanding what's going on.
I consider the judicious use of resources to be part of my job as a software engineer. A development team that isn't considering how they can reduce spend, tidy up, or right-size their resources is a massive red flag to me. Organisations frequently shoot themselves in the foot by shifting that responsibility away from the development team. The result is usually factional infighting and more meetings.
It's not really the same spot in that your paying monthly rather than upfront. Devs tend to think about total $, the business/accountants do care about Opex vs Capex.
Also it's going to be simpler to provision your base (commited use) on the cloud and then handle bursts on the cloud, than it is to have your base on prem and burst to the cloud.
> It's not really the same spot in that your paying monthly rather than upfront. Devs tend to think about total $, the business/accountants do care about Opex vs Capex.
You can buy physical servers in leasing ,turning it into opex
You can also rent them for little bit extra via managed dedicated servers from vendors like OVH.
And other point I also seen used to lie about cloud cost is saying you save so much on engineers.
...while forgetting to have sane on-call rotation for cloud you also need at least 3 people on that rotation that are also clued in on cloud operation enough. Sure they can be "developers" but if your app architecture requires so little maintenance and flea removal that they are not doing ops jobs much, chances are so would it in either rented or dedicated server env.
That is not really a difference, you may as well lease your server farm in the basement, practically the same cost as buying it, just as a monthly payment with the supposed "advantages" the business people might care about.
> If your business invests in physical servers anticipating strong growth next year then later finds out actually we're going into a recession and those servers are no longer needed, then that's a sunk cost.
Yes, but that sunk cost is probably still lower than what you paid AWS for the option to scale up and down.
This. And I think people tend not to understand how little actual hardware they are paying for when using AWS et al.
A really cheap server leasing deal will cost you yearly about as much as the purchase price of the server. With opaque AWS services it is probably more like a month of subscription to pay for the hardware that you are indirectly using.
I worked for a global company that maintained it's own "cloud" of VMs that we'd use for development purposes.
They were entirely unusable.
Opening a relatively small file in notepad could take multiple minutes. OS click and typing response times were measured in seconds.
Despite wasting thousands of developer hours each year, they refused to upgrade their data center. Probably because doing so would have been a major budget fight that requires an executive to actually advocate for something instead of making their characteristic animalistic grunts of agreement.
For better or worse I haven't seen the same issue with cloud expenditure. It seems to be perceived as a necessary expense, rather than the engineering department getting ideas above their station.
I just spent the better part of two years advocating, pushing, and fighting for months to add new bandwidth to our datacenter.
Thankfully after they understood the problem it only took 8 months of procurement, techs going to the data center 10+ times with endless screw ups, and everyone pointing the finger at each other.
While the cloud sucks in many ways the traditional setup has big problems as soon as you hit a midsize company ime.
A cloud vendor (who will be nameless as I signed an NDA specifically that prevents me from disparaging them; but one of the big three) ran out of capacity for me and it was 3 months before they managed to fix it. -- that was with a couple million a month in spend.
Cloud is still servers; you just depend on someone elses capacity management skills and you hope that there isn't a rush to populate a location (like when a region goes down and everyone's auto-provisioners move regions to yours)
Barring exceptional circumstances, I don't have to fight that fight at the cloud provider though. Their business is more likely to be amenable to maintaining and expanding reasonable levels of capacity.
I have to deal with a grumpy finance guy that thinks my whole department is overpaid already, especially so if we might use the dreaded `CapEx` word.
I think the main point here is that there is no limit to incompetence. And sure, having your own servers allow for some goofs that won't happen with cloud (the opposite is also true). But your org had the means to fix the issue, and they choose not to. That has fundamentally got nothing to do with technology choice.
Or maybe there's a mid point. It's not datacenter or cloud. There are providers offering physical servers for rent for example. Lots of combinations in-between.
And that you can also lease servers directly from vendors like OVH so you don't even need to bother with the "drive to datacenter and install it" part. It's more expensive but still far cheaper than cloud
Most companies will pay way more for the engineers maintaining their on-premises infrastructure than they would for AWS. On-premises still makes sense when you reach a certain scale. When you reach a certain scale.
They kind of need to be there anyway, physically maintaining servers turns out to be a miniscule part of the whole maintenance. If you really care about uptime you still need people on-call who can intervene as necessary.
It's not a minuscule part of a small company. I made the point that on-premises makes sense after a certain scale.
Once you have on-premises you need people that know switches, routers, rackmount server, hardware, virtualization, etc, plus keeping all of that properly maintained (security patches, IaC, periodic updates, analyzing performance, making sure it's properly architected, etc).
I often see people saying it's the same cost or less but it's really not. Unless you have no idea what you should be doing.
I don't know, I worked at a few companies that did this early in my career (early 2000s), and it was just the devs or the sysadmin of the office IT that did this sort of thing. There are lots of people who know enough about switches and routers to get them up and running.
Virtualization, IaC, analyzing performance, right architecture etc is all for later, when you've grown enough to need that.
> Virtualization, IaC, analyzing performance, right architecture etc is all for later, when you've grown enough to need that.
Yeah, I think it might be a different perspective about when that all should be done.
I tend to do that right from the beginning because I often see it snowball later on and nobody ever fixes it or does it "properly" (in my opinion, possibly not the right one).
Using insurance to cover unexpected costs is always a gamble, one way or an other. A business that invest into physical servers could sell of those servers if they later find out that there is a recession, which might cost more or less compared to a cloud solution.
If a business invest into a cloud infrastructure and create a binding contract for 5 years, only to find out that they actually want to abandon that project a year later, that is also a sunk cost. Long term contracts tend to be cheaper, so its a trade off between saving money vs risk.
It all depend on the risk analysis, how risk averse one want to be, and the economics/liquidity needs.
It depends on your timing. If you're extremely unlucky, you'll buy the new set of servers and the recession will hit right after you sign the PO. Probability says you're not likely gonna be that unlucky, so the recession will hit probably elsewhere in the physical servers' life cycle. A recession hits, and now there's a focus on cutting costs. With AWS, you don't have much choice - if you stop paying the bill, the servers evaporate into the cloud. Physical servers don't. You can change their replacement schedule and just wait arm few years more to replace them. Hopefully the recession has passed by then and you can buy a whole new pile of servers.
Really though, it seems like a hybrid on-prem/cloud approach is one to consider. Software like Anthos eases this, though there are also pitfalls with this approach too.
We have some DB servers that occasionally need to do very large batches of transactions. They run all month with a couple of CPU's, and a small amount of ram to make sure they are 'caught up' with production, and before the batches are run, get shutdown, and changed to 32 or 64 CPU monsters. An hour or two later, they go back to the 2 cpu servers again. In a non-cloud shop, we would have to size our hardware for that maximum batch size.
To be fair to AWS, they do work really hard to (at least at an account level) to optimize workloads with you. They do this so overall you'll move more workloads to them.
its quite simple, if workload x can be done 100% cheaper on-prem then its an obvious move (probably) if AWS manage to get that closer to 30-40% then the operational benefits of using AWS make more sense, more workloads, more total spend.
An easily tested compatible upgrade that gets a free performance boost… vs lots of engineering effort to rewrite… yeah that’s just not going to fly with management. Who are probably looking at the 25% performance boost as a 20% cost reduction not a 20% speed increase
The only problem with that is that Docker lambdas boot slower than lambdas with the built in runtime (not ridiculously slow, but could be 2x or something). God help you anyway if you’re trying to do something latency sensitive on Lambda, but if you are then you probably don’t want to add more time for a docker pull.
The situation does keep changing - AWS does optimize things.
I'm not so sure it's a black/white true/false. Depends on what goes in the docker image. It's something like for larger deployments docker is faster but for small deployments it's the other way.
We've actually observed the opposite at our company. Moving from a Python 3.8 built-in to Docker based changed our response times from about 40ms to 30ms on average.
> Which is good lesson, and a good story, but there’s a kind of irony it’s come from an internal Amazon team. As another poster commented, I wouldn’t be surprised if it’s taken down at some point.
Why? Using the model they switched to (which uses a different set of AWS services) instead of the model they switched from is a recommendation that the AWS tech advisers that are made available to enterprise customers will make for certain workloads.
Now when they do that, they can also point to this article as additional backing.
Have you had AWS tech advisers advise teams in your company to go with this stack? Because I haven't.
AWS doesn't have an equally distributed interest in selling all of its products. Some AWS products exist because customers need/demand them and others exist because they provide higher margins and tighter lock-in to Amazon: the first type of products are great for customer acquisition, the role of their sales folk is to then convince people using the former to migrate to the latter.
I've never knowingly had an AWS solutions architect recommend something because it would make AWS more money in the short term. The most frequent advice I've seen from them has been on how to give AWS less money by making use of different features, or changing how particular services are being used.
You sound very confident in your estimation of other peoples' motivations and skills. Do you imagine AWS solution architects coming to you directly with "you should pay for this service because it makes more money for AWS"?
I've done the AWS solutions architect associate level cert and I can tell you first-hand experience that in order to pass the exam you need to memorize a lot of AWS propaganda that was written primarily to optimize AWS profit, not to optimize customer satisfaction. How many of those solution architects take those materials with a grain of salt vs how many of them genuinely believe that crap, I don't know.
I guess it depends on what you mean by "AWS tech advisers" ... I've had two different AWS recommended partners advise us to go to this stack, one of the partners even tried to explain that despite more than doubling in costs we would "make it up in faster development".
Aurora is I think pretty simple to move away from, since it's just fully compatible Postgres or Mysql. We even use a local postgres for development purposes against an Aurora solution.
Nope. AWS makes it dead simple to move from RDS to Aurora by clicking a button. There's no way to move data from Aurora to RDS short of doing a SQL dump and reloading everything that way. I found this out when my previous employer was looking at moving from RDS to Aurora.
> > Aurora is I think pretty simple to move away from, since it's just fully compatible Postgres or Mysql. We even use a local postgres for development purposes against an Aurora solution.
> Nope. AWS makes it dead simple to move from RDS to Aurora by clicking a button. There's no way to move data from Aurora to RDS short of doing a SQL dump and reloading everything that way. I found this out when my previous employer was looking at moving from RDS to Aurora.
I got a bit of a chuckle out of this. There's no way to move from Aurora to RDS short of... 2 minutes of actual work and a lot of waiting around due to the limitations of the hardware?
I get that it's not as easy as a literal button click, but this isn't vendor lock in.
If you can't stream changes and have to take downtime for a migration then you effectively have vendor lock in if you are serious enough about your database.
Physical Replication should be something any database can offer given its something cross database migrations used decades ago with no problem.
I'm intentionally ignoring any of the sarcasm in your comment. The time needed for a db dump is always dependent upon the amount of data. This is true regardless of the db software or where it's running.
Sure, but you don’t really expect to swap databases with a huge data store without any downtime, do you? I’m not aware of any technology that makes that easy.
If you were the CEO and your engineer and someone said, "2 minutes of actual work and a lot of waiting around due to the limitations of the hardware", would you interpret that as "2 minutes of engineering time"?
Obviously I'm going to spend a lot more time communicating the details of the situation to the CEO of a company that is paying me, than I'm going to spend communicating in a Hacker News comment. But as it turns out, no amount of communication is going to be effective if people don't bother to read past the first opportunity they see to jump in with a correction, even if that means stopping reading mid-sentence.
In that situation I would guess the one-click tool doesn’t really handle everything you’d need either so I don’t get what the point of the comparison is.
Nor am I but if we go back up the claim was that they were making it much easier to get in than get out, but unless you're telling me that the one-click tool somehow solves all the issues of migrating a large production database that's in use the difference between the two is a minuscule amount of active work.
I'm not sure what I was supposed to take away from your cryptic sentence. Is there a two minute solution to this problem that you are smugly keeping to yourself so you can mock people replying to you?
My guy, read this whole sentence, which has remained unchanged this entire conversation:
"There's no way to move from Aurora to RDS short of... 2 minutes of actual work and a lot of waiting around due to the limitations of the hardware?"
You seem to be having trouble getting past the word "and", so I've helpfully italicized the part you've repeatedly missed or ignored.
Now sure, that's a bit vague, but if you want more details it might have been advisable to ask a question rather than simply ignoring half the sentence because you don't understand it and jumping in with a correction.
And honestly, even if it's vague on some details, there's no universe in which "2 minutes and a lot of waiting around" = "2 minutes". Whatever vagueness you might accuse me of, that fact isn't vague.
that is fair answer! AFAIK, there are two things that consider:
* Aurora do have some vendor-locking feature if I'm not wrong?
* moving from Aurora to PostGres will lead to downtime of 2 minutes + unknown waiting, where this is not a case when you convert from PostGres to Aurora.
I haven't failed to consider that, you've just failed to read where I explicitly mentioned that.
Consider: is that impracticality caused by Amazon creating vendor lock-in? Or is that impracticality caused by the fact that reading terabytes of data from storage, transferring it over the network, and writing it into storage is inherently slow because of the physical limitations of hardware, no matter what vendor you're using?
It's a bit odd for me to be in the position of defending Amazon here. I genuinely don't like them, don't use them, and generally do think they're guilty of creating a lot of vendor lock-in. But this is legitimately not an example of any of that.
You're really claiming you can read my mind to know what I have and have not considered right now, despite me bringing it up specifically. Alrighty then.
As is, I've no responsibility to show you anything, and you're just making unwarranted assumptions about what I have and haven't considered, based on a pretty selective reading of what I've said.
Yes, still "2 minutes of actual work and a lot of waiting around due to the limitations of the hardware" which is what I said. Perhaps try reading the whole sentence next time?
If you talk about no vendor lock in, and you'd want to take your database then to a competitor, like Google Cloud, Azure, or on-premises, wouldn't you exactly expect to do a SQL dump and reloading everything? To me, the one-click move from RDS to Aurora you describe is a nice shortcut, but it doesn't invalidate that you can still do the former if you wanted to move to the competitor. Vendor lock in seems more that you've architected your application against a system that only exists on AWS, like SQS or S3 (although, I guess, competitors offer compatible APIs for some of those, I'm not entirely read up on the state of things there).
Seems a bit of a dark pattern to have shortcut to onboard and not offer the same shortcut to offboard.
Just like easy subscribe-online publications that will have you call during 2 hours with a rep pushing you discounts or whatever to cancel such subscription.
I'd characterize this asymmetry (convenient shortcut IN, standard export OUT) as a predictable, transparent, minor annoyance -- not a "dark pattern" representing deceptive or unethical practices.
Huh. I suppose you can. The pricing looks a little opaque though, and the fact that it took 3 hours after I wrote my comment for yours to show up kind of implies it's a bit of an obscure service.
I will also mention that the AWS team we were working with on this didn't mention DMS, and, when directly asked, literally told me there was no easy way to do an Aurora -> RDS migration.
Aurora significantly modifies the internals of the DBs, particularly the storage layers. It also makes large changes to how memory is used for Postgres. Query plans can be quite different than with the vanilla version. Once you tune and create indexes based on Aurora's characteristics it's going to be a pain to retune for the unmodified version. Aurora also introduces nasty bugs that don't exist on the RDS version such as a memory leak I found was periodically restarting our master. The Postgres team produces highly reliable code, but I don't trust Aurora's hacks on top of it.
I feel like it’s an object lesson in using the right solution for a problem. Step functions do not appear to me to be something that you’d use for things that need to be executed multiple times per second.
Having occasionally looked at them for workflow driven tasks I'm not sure what the use case for Step Functions is, unless your workflow being called once an hour or something they seem infeasibly expensive for what they offer, and somehow manage to be more complex than just writing some code to model the workflow.
It's a BPM product. If you have a highly regulated workflow that has to be changed a lot by multiple parties, these products start to make sense. The AWS step functions aren't that great in the BPM and workflow automation either, but I imagine AWS just wants to have a first party offering.
I'm pretty happy with the monolith that we run at our business and this seems to validate our decision to stick to that monolith, but I'm also pretty confident that where we use AWS Lambda, serverless is absolutely the right way to go.
For example, I've written a Lambda application to reply to webhook calls and send API calls whenever those come in. It costs maybe $2 per month to run in compute and requests. Would that make more sense to rewrite as a monolith and run on EC2? I really doubt it.
In your example, you compare Lambda against a separate monolith for handling the webhooks, but with a monolith wouldn't the comparison be between lambda and just adding a route and controller (or equivalent) to the monolith?
I'm more thinking of rewriting the application (a bunch of Lambda functions + API gateway + random bits and bobs) as a monolith and running that separately on an EC2 instance (or any other VPS).
In this article, they didn't bolt the serverless architecture onto another existing monolith, but rather rewrote the Step Functions and Lambda functions to be a single ECS task.
But background tasks are a thing. You could add a webhook endpoint to your monolith that writes a background job. Then your background worker (running on the same ec2 because it’s hardware requirements look pretty low at $2 a month in lambda) runs the job. $2 a month is now $0 since it’s running next to your monolith on the VM you’re already paying for.
It really depends on the quantity & scale though right?
If in my entire estate I have a single shell script that I run - wow lambdas / serverless are amazing.
When I have 200 things that cost $5/mo each to run but fit nicely on a single 8core/32gb ram server.. then this lambda stuff starts to seem crazy expensive right?
For some Alexa integrations it is neat and convenient, but I went back to hosting such small interfaces as a service on another server. Not an EC2 instance, just another hosted unmanaged server. They are as cheap as they can get right now.
I'm not really interested in the operational overhead that brings for these small services. Cost-wise they might be just about neck-and-neck, but at least I don't need to worry about the server going down, or having outdated software. Lambda gives me scaling, load balancing and redundancy for that $2.
From experience I say that the operational overhead to host on Amazon isn't trivial at all.
I like AWS and I would still recommend it. It saves some work but also creates new stuff to do. Especially if you also want the costs be manageable. Automatic updates, configuring a firewall + reverse proxy with automatic certificate renewals and you favorite deployment mechanism isn't more complicated or labor intensive than managing a small application with AWS. You need to interface it just like software you run on your server.
One of the services I host needed to be authenticated by IP. Happens. You easily get a static IP on AWS for incoming traffic. No problem and cheap too. Now try to get one for the other direction... Possible too, but maintenance just became at least as labor intensive as hosting your own machine. AWS just has to fit your scenario and I think many people overestimate how comparatively easier it has become to host a server with feasible security today. Chances are your databases would be less public than if you skip the AWS documentation.
I think you might be unintentionally arguing with a strawman, as everyone else here is talking about using monoliths instead of that.
Few people want to administer a bunch of micro services themselves, but running a single service on a box is pretty low effort, even if you duplicate it for fail over/redundancy
By "using monoliths", do you mean bolting all code you write into a single runtime, even if they are not the same service? Because that's not what was in this article. Instead, they took Step Functions and a bunch of Lambda functions, and created a brand new monolith from that.
In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.
"mono" stands for one/alone/singular, so monolithic is kinda defined to be exactly that, yes.
You can still have multiple monoliths, but they wouldn't communicate with each other and would be entirely separate applications.
I think it is fine. There are scenarios were you need distributed and there are scenarios that you don't.
IMO, distributed software is more practical for working development than for technical reasons.
We all know from basic stuff that performing software comes from single structures that does not require packing and unpacking data
But scaling large applications is hard, and it was much more expensive back then.
Now that we overreacted to microservices we will overreact to monoliths again. And we will bounce many more times until AI take our jobs and do the loop itself
The cynic in me (so like 93% of me) reads this as a "Instead of abandoning AWS altogether, we changed how we use AWS, but most importantly we're still on AWS"
As an exaws senior dude we never looked at our service stack as a sell at any cost, but as a continuum of service offerings that could be assembled to be more cost optimal at higher operational burden to (mostly) ops free at a higher premium. The goal was to provide a lego kit of power tools and disappear from view tools. At least in my org we never tried to upsell or convince customers of architectures that accreted revenues at their expense, we tried to honestly assess their sophistication and desire for ops burden and complexity vs cost savings by building it themselves with the lower level kit. By our measure using aws brought us business, and we were generally more motivated by customer obsession over soaking them. I know Andy definitely had that view and drilled it into our collective heads. In many ways as an engineering minded person I appreciated the sentiment as I enjoy solving problems more than screwing people out of their money for sport.
Exactly. You could easily frame it as "if AWS seems expensive, you're using it wrong". That an internal team could get it so wrong is testament to how difficult it is to get right, but of course, there's a consultant for helping with that.
The smoking gun is probably the box that was previously labelled "Media Conversion Service" (Elemental MediaConvert - easily 5-6 figures/mo. for a small amount of snappy on-demand capacity, or crippled slow-as-molasses reserved queues) now labelled "Media Converter" running on ECS. For example, vt1 instances are <$200/mo. spot and each instance packs enough transcode to power a small galaxy, for fine-grained tuning an equivalent CPU-only transcode solution isn't that much more expensive either.
At some point the industry will wake up to the fact the AWS pricing pages are the real API docs, meanwhile dumb shit like this will keep happening over and over again, and AWS absolutely are not to blame for it, any more than e.g. a vendor of cabling is guilty of burning down the house of someone who plugged 10 electric heaters into a chain of double-gang power extension cords
Exactly right. Most cloud victims are people who have faith instead of cost calculations. DHH & co. are the prime example. It seems even Amazon has such people. I guess hiring is much harder nowadays.
That was my reaction too. I know Microservices doesn’t equal cloud, but putting a big monolith on a big server is tangential to AWS interests to say the least!
> but there's a kind of irony it's come from an internal Amazon team
Not at all. My time working with AWS reps, they never pushed a particular way of doing things. Rather, they tried to make what we wanted to do easier. And the caveat was always to test and make decisions on what was important to us. This isn't an anti-AWS article. Rather, it's exactly the type of thing I'd expect from them. Use the right tool for the right job.
>Microservices and serverless components are tools that do work at high scale, but whether to use them over monolith has to be made on a case-by-case basis.
Tldr build the right thing.
>"AWS sales and support teams continue to spend much of their time helping customers optimize AWS spend so they can weather this uncertain economy," Brian Olsavsky, Amazon's finance chief, said on a conference call with analysts.[0]
Amazon isn't afraid of this trend, they're embracing it. Better to cannibalise yourself than be disrupted by someone else
Around 2008 the idea of microseconds were looked down on, until they weren’t.
The key is to look down on nothing, become competent with multiple architects and know which ones not to implement in a use case if the one to use isn’t clear right away
I don't read it like that at all. Both solutions use the Amazon cloud. Only in one solution you distribute a lot of processes, just because it's possible, and easy to code. When they figured out that rampant distribution was costly, they put more thinking in keeping a lot of computation in the same place (so, "monolith", but still in the cloud). No surprise, they found great savings. If they hadn't, they wold not have written about it. But they had to put some (most likely major) effort into redesigning the application.
Probably an unpopular take and my experience is almost 10 years old, but I would be surprised to see the Amazon I worked at try to bury something like this. If the product isn't what the customer wants, it isn't what the customer wants - move on and build something the customer wants.
Yes agreed there were some funny business like not selling Chromecast, but the guiding principle was generally to make things customers want...
Do you think the Lambda team want people to use as many of their services as possible even when it's not actually appropriate and there are better architectures and approaches available? I doubt that. They probably understand that Lambda is a good service for some things and not for others, and using it as a part of deploying things to AWS is a great idea but using it where it doesn't fit makes all of AWS look bad (in particular, hard to use and expensive.)
> Do you think the Lambda team want people to use as many of their services as possible even when it's not actually appropriate and there are better architectures and approaches available?
They most definitely want to as that would most likely mean more money (and promotions) is flowing there.
This is simply incorrect. ECS doesn't cost anything other than what you're paying for the EC2 instances that you place your tasks on. Fargate does, but that's not what they're using.
I know there are nuances in the article, but my first impression was it's saying "we went back to basics and stopped using needless expensive AWS stuff that caused us to completely over architect our application and the results were much better". Which is good lesson, and a good story, but there's a kind of irony it's come from an internal Amazon team. As another poster commented, I wouldn't be surprised if it's taken down at some point.