3 ms·

That's fair, and I'm not dogmatically opposed to the cloud. But when you have underpowered cloud machines you end up having different machines for email, for we

by jdvh 5y ago

That's fair, and I'm not dogmatically opposed to the cloud. But when you have underpowered cloud machines you end up having different machines for email, for web workers, for caching, and so on. The complexity you introduce by making your app scalable in that way you just don't have when you stick everything on 1 dedicated server. With dedicated machines I don't need to create a distributed architecture prematurely. It takes us some time to set up dedicated machines, but less than a day. Ansible helps a bunch.

eropple 5y ago
Email sending, web workers, etc. can all feed off of the same repository, running on different hardware, and have functions subdivided by DNS. "Monolith as services" is a super common pattern. The closest thing I can tease out of this claim that seems like a significant practical criticism is that you need a resilient communications channel for talking from, say, core logic to an email sender--but you need that on one node too, if you aren't using a the right datastore for the job you're asking to staple your hand to your face no matter how many nodes your application runs on. And these days it's pretty trivial to use a lot of AWS free tier stuff--or other clouds, but let's be real, AWS gives you A Lot--for much of what you describe. CloudFront is not my favorite CDN but they give you a bonkers amount of free transfer these days. DynamoDB as an object cache, if you don't want to pay for Redis. SQS is free to like a million API request a month and you can stick a lambda on the other end of it to handle offline/async tasks. And SES turns email sending into an API call. If your concern is velocity, then cloud stuff is almost unassailable. If your concern is price, better cloud stuff is hard to beat, too. If your concern is portability, I hope you're already profitable and that it's worth your time to worry about it.

by jdvh 5y ago

eropple 5y ago

Email sending, web workers, etc. can all feed off of the same repository, running on different hardware, and have functions subdivided by DNS. "Monolith as services" is a super common pattern. The closest thing I can tease out of this claim that seems like a significant practical criticism is that you need a resilient communications channel for talking from, say, core logic to an email sender--but you need that on one node too, if you aren't using a the right datastore for the job you're asking to staple your hand to your face no matter how many nodes your application runs on. And these days it's pretty trivial to use a lot of AWS free tier stuff--or other clouds, but let's be real, AWS gives you A Lot--for much of what you describe. CloudFront is not my favorite CDN but they give you a bonkers amount of free transfer these days. DynamoDB as an object cache, if you don't want to pay for Redis. SQS is free to like a million API request a month and you can stick a lambda on the other end of it to handle offline/async tasks. And SES turns email sending into an API call. If your concern is velocity, then cloud stuff is almost unassailable. If your concern is price, better cloud stuff is hard to beat, too. If your concern is portability, I hope you're already profitable and that it's worth your time to worry about it.