Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
Unfortunately I have to disagree with your previous article at different levels. Back then when we were building monolithic applications deployments were easy. Everything was built, tested and deployed in one go. Errors made solution fail to compile or fail to pass tests. Anyone could run the solution on their PC in debug mode without additional efforts and complex tools (running Linux servers in a docker containers in WSL Hyper-V container on Windows 10). Boy, I wish half of our deployment problems were not caused because one of our developers did not have enough domain knowledge to know his changes break one out of other tens of services the app is composed of. And nearly 90% unit test coverage and PR code reviews are not helping at all. Microservice architecture requires in addition to unit testing also thorough integration testing which usually means secondary identical environment.
Debugging monolithic application is a breeze compared to microservice based solution. Usually running the solution in an IDE of your choice in debug mode is enough. Over the time IDEs and their debugging capabilities have evolved to a tool that does the job perfectly. Comparing this to debugging multiple microservices, stepping in and out of domains, trying to figure out if the problem is not related to out-of-order delivery, required consistency (instead of eventual consistency) or trying to make sense out of DTOs that change form in each microservice is IMHO insane.
Complexity has increased dramatically by stepping towards microservices. That monolithic application that was once running on an expensive powerful server would also run perfectly fine in todays commodity hardware. It's not because microservice architecture makes things less demanding. It's the opposite. You're now probably running docker within a VM in shared hosting datacenter. This adds 2 additional unnecessary layers with unpredictable latencies to your solution. Your services all of a sudden perform worse than usual because some other cloud hosting company customer started heavy invoice pdf generation for their customers and your VM is live migrated to another cluster host. Good luck debugging that!
Back then when you had your own physically rented server and there was a problem you could fire loads of various tools and pinpoint exactly where the problem is. Nowdays you deal with mostly cloud provider issues and unnecessary CPU stealing by other customers on the platform. Forget about decent SQL server performance on local SSD RAID array. Deal with NAS storage with increased unpredictable and heavily varying latencies. You need more Database power? Scale horizontally by deploying sharding or data replication increasing latencies even more! Once you had loads of memory for your main database server that was performing well because you designed your infrastructure for it. Now you probably have database server running in each container either as a data storage, KV store, response cache or message queue store, each running with minimum memory for page cache making it to query already slow NAS storage for data even more. Forget about 20k IOPS you could have with local SSD storage. Your provider said 2k IOPS should be enough for everybody. Should you need more, you can pay as much as a cost of one 1TB enterprise SSD disk each month to have double the IOPS! But don't worry you can always scale horizontally, your company will pay for it! What was once a bunch of resources for future growth in a physical server is now considered minimum to start with simple microservice architecture.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Unfortunately I have to disagree with your previous article at different levels. Back then when we were building monolithic applications deployments were easy. Everything was built, tested and deployed in one go. Errors made solution fail to compile or fail to pass tests. Anyone could run the solution on their PC in debug mode without additional efforts and complex tools (running Linux servers in a docker containers in WSL Hyper-V container on Windows 10). Boy, I wish half of our deployment problems were not caused because one of our developers did not have enough domain knowledge to know his changes break one out of other tens of services the app is composed of. And nearly 90% unit test coverage and PR code reviews are not helping at all. Microservice architecture requires in addition to unit testing also thorough integration testing which usually means secondary identical environment.
Debugging monolithic application is a breeze compared to microservice based solution. Usually running the solution in an IDE of your choice in debug mode is enough. Over the time IDEs and their debugging capabilities have evolved to a tool that does the job perfectly. Comparing this to debugging multiple microservices, stepping in and out of domains, trying to figure out if the problem is not related to out-of-order delivery, required consistency (instead of eventual consistency) or trying to make sense out of DTOs that change form in each microservice is IMHO insane.
Complexity has increased dramatically by stepping towards microservices. That monolithic application that was once running on an expensive powerful server would also run perfectly fine in todays commodity hardware. It's not because microservice architecture makes things less demanding. It's the opposite. You're now probably running docker within a VM in shared hosting datacenter. This adds 2 additional unnecessary layers with unpredictable latencies to your solution. Your services all of a sudden perform worse than usual because some other cloud hosting company customer started heavy invoice pdf generation for their customers and your VM is live migrated to another cluster host. Good luck debugging that!
Back then when you had your own physically rented server and there was a problem you could fire loads of various tools and pinpoint exactly where the problem is. Nowdays you deal with mostly cloud provider issues and unnecessary CPU stealing by other customers on the platform. Forget about decent SQL server performance on local SSD RAID array. Deal with NAS storage with increased unpredictable and heavily varying latencies. You need more Database power? Scale horizontally by deploying sharding or data replication increasing latencies even more! Once you had loads of memory for your main database server that was performing well because you designed your infrastructure for it. Now you probably have database server running in each container either as a data storage, KV store, response cache or message queue store, each running with minimum memory for page cache making it to query already slow NAS storage for data even more. Forget about 20k IOPS you could have with local SSD storage. Your provider said 2k IOPS should be enough for everybody. Should you need more, you can pay as much as a cost of one 1TB enterprise SSD disk each month to have double the IOPS! But don't worry you can always scale horizontally, your company will pay for it! What was once a bunch of resources for future growth in a physical server is now considered minimum to start with simple microservice architecture.