Add a comment

 

Re: Distributed big balls of mud

Late to the party but... "Caveats apply, but monoliths can be built quickly and are easy to deploy, but they provide limited agility because even tiny changes require a full redeployment." This seems really irrelevant to me from an architectural perspective. The key to a distributed design is how the interfaces are exposed. How the system is deployed is not an architectural concern but more of a operational one. For example, lets say I have 3 servers and 3 services (to keep things simple.) I can build one thing and deploy it to three places. One build, three deployments. Every time I change one service, I build, test, and deploy the bundle. Or, I coule have three builds and deploy them to a) one server each, or b) to each server. If I pick a, I have a lack of resiliency. One server goes down and one or my services goes down and for sake of argument (and in my reality), all need to be operational in order for the business to operate. So we are down. That's bad so we'll go with b. So now, I've go three services running on three servers. 3 builds, 9 deployments. And to anyone consuming my services, it looks exactly like the bundled deployment. OK so now we want to change one service. We can just change it and deploy that alone. So one build, 3 deployments i.e. the same number as for the bundled deployment. But what about testing? In theory, you can just test the one thing and if your services are really independent of each other, then it might make sense to do this. But in my world, everything is related. Services need to be interoperable. One service consumes the things created by another. Consumers need to be able to call multiple services and derive things from the combinations of their responses. So not testing everything is crazy. We've moved away from independently deployable services because they created to development overhead, interoperability problems, and operations headaches. The benefits on a rational platform are basically a faster deployment from say 10 seconds to maybe 5. Not worth it. We might consider dividing the bundles by domain but we're leaving the idea of independently deployable services and not looking back.

Re: Distributed big balls of mud


Title
Body
HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).