3 ms·

But how monolithic were our monoliths anyway? Take your bog-standard ecommerce solution, built with a LAMP stack. Okay, we've got a php process. Let's put our

But how monolithic were our monoliths anyway? Take your bog-standard ecommerce solution, built with a LAMP stack. Okay, we've got a php process. Let's put our business logic there. Okay, I need a database. With current cloud practices, that's probably going to be deployed in a different machine. We've got our business logic service and our datastore separated by a network bound from the get go. Okay this is not very performant, I need to cache some data. Let's add a redis instance in our cloud provider. I guess this we'll be our cache service. Okay we need to do full-text search, let's add an elasticsearch cluster through our cloud provider. Okay I need to store users. We can built that into our business logic core, of course, but screw that. We are using Auth0. I guess our "user service" is distributed now. Okay, my php process can't keep up with all this requests, let's scale this horizontally by deploying multiple php processes behind a load balancer! Okay, now I need to do some batch processing after hours. I could add a cron job for that, but I don't want to deal with everything needed for retrying/reprocessing/failure handling plus now that it's a multi-instance deployment it's not even clear which process should do this! Let's put this work in a Lambda from our cloud provider. So until now, we had a star architecture where everything talked to our business core. But adding this lambda that will talk directly to other services without consulting the core we've lost that. Now, stripping out the business core into its constituent parts doesn't sound so strange, does it?

luhn 6y ago
Yeah, that's a terrible idea, so don't do something like that. You don't need to break up your monolith to run cronjobs. My setup: I have async worker running alongside my application. Same codebase, same environment, same monolith, just instead of accepting HTTP requests it pops tasks off a queue. The framework handles retrying/reprocessing/failure. To run cron tasks, I have CloudWatch Events -> SNS -> HTTP endpoint in the monolith which pushes the cron task into the queue. And this isn't some unusual setup. This is something that people have been dealing with for a very long time, long before Lambda came into existence. Most web frameworks have async tasks built-in or an integration with a framework that can do async tasks.
- morelisp 6y ago
  Now you need to upgrade. Your HTTP request handling takes like maybe 2s at most bring up a new instance and drain the old one. But you have one daily cron job that takes eight hours, and another that only takes 1s but needs to run hourly. Now you need to upgrade to a new version, which requires an incompatible DB migration affecting the request handling and the hourly job. The long job started at 2PM. How do you do the upgrade, without someone needing to stay late? (If it's e.g. PHP this gets even worse due to lazy package loading, you don't need a DB migration just a changed import path.) I'm not a fan of microservices, especially the ridiculous factoring I see in lambda-style approaches today. But one of our biggest PITAs was a "horizontally scalable monolith" that after 7 years has accrued so so many responsibilities it's either impossible to find a time slot for an upgrade with zero/low downtime, or we have to plan & develop dealing with shared storage where half may upgrade one day and half the next - all the operational overhead of SOA without the benefits.

luhn 6y ago

Yeah, that's a terrible idea, so don't do something like that. You don't need to break up your monolith to run cronjobs. My setup: I have async worker running alongside my application. Same codebase, same environment, same monolith, just instead of accepting HTTP requests it pops tasks off a queue. The framework handles retrying/reprocessing/failure. To run cron tasks, I have CloudWatch Events -> SNS -> HTTP endpoint in the monolith which pushes the cron task into the queue. And this isn't some unusual setup. This is something that people have been dealing with for a very long time, long before Lambda came into existence. Most web frameworks have async tasks built-in or an integration with a framework that can do async tasks.

morelisp 6y ago
Now you need to upgrade. Your HTTP request handling takes like maybe 2s at most bring up a new instance and drain the old one. But you have one daily cron job that takes eight hours, and another that only takes 1s but needs to run hourly. Now you need to upgrade to a new version, which requires an incompatible DB migration affecting the request handling and the hourly job. The long job started at 2PM. How do you do the upgrade, without someone needing to stay late? (If it's e.g. PHP this gets even worse due to lazy package loading, you don't need a DB migration just a changed import path.) I'm not a fan of microservices, especially the ridiculous factoring I see in lambda-style approaches today. But one of our biggest PITAs was a "horizontally scalable monolith" that after 7 years has accrued so so many responsibilities it's either impossible to find a time slot for an upgrade with zero/low downtime, or we have to plan & develop dealing with shared storage where half may upgrade one day and half the next - all the operational overhead of SOA without the benefits.