Add a comment

 

Re: Distributed big balls of mud

Yep, the second you introduce distributed, you need to leverage infrastructure that addresses network latency, fault tolerance, message serialization, unreliable networks, asynchronicity, versioning, varying loads within the application tiers etc. etc. Otherwise you're coding it yourself, a la NetFlix OSS and I suspect that is one of the main reasons for monolithic shops not being interested. Takes top level talent at the moment, not something all enterprises have access to. I can't see how a microservice would ever be as easy to create as a class, too many human-based design decisions involved, but I do share your concern that are plenty of traps to fall into. I do agree and that monotlithic applications designed in a certain way would reap some of the microservice benefit, but monolithic would never be able to be as testable, refactorable, approachable to a new developer, or as friendly when scaling the team. I think your blog on layer vs component design (an an architecturally evident coding style) provides a very balanced view of this, particularly w.r.t testability. Lastly - In some cases, monolithic containers are optimized for a single app or binary deployment unit, but often they must host a variety to achieve density or respond to business pressure to leverage expensive investment(s). Using microservice approach you can tweak each container for the purpose and context at hand. As vendors start to provide some of this "missing" infrastructure, devs will naturally be more free to concentrate on the design decisions inherent in distributed systems and will be less prone to err.

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).