Monolith First (2015)

Post by JBReefer » Sun, Jul 16, 2017, 3:22 AM UTC

taurath wrote: post #13

eropple wrote: post #10

Earlier quoted context omitted.

I do devops. I consult for startups. And while it would make me a lot more money in the short term to fuel their microservice-first, sparkly-architecture aspirations, this is exactly the approach I take when I pour some water on that. Your Big Ugly Monolith will get you where you're trying to go if anything will. You don't need services, you don't need microservices, you don't need some bloggable-as-heck Kubernetes s…

Couldn't agree more - inheritance chains and heavily stateful instruction environments are the number one blocker to eventually decoupling a monolith. The "enterprise" code style is absolutely what you need to avoid in a startup.

Post by jaxn » Sun, Jul 16, 2017, 3:28 AM UTC

Post by Animats » Sun, Jul 16, 2017, 3:47 AM UTC

dasil003 wrote: post #77

Animats wrote: post #36

Earlier quoted context omitted.

Rule of thumb: if you have two "service" talking to the same set of data in the same general-purpose datastore (i.e., not pub-sub, not opposite ends of a job queue), they're the same service. Why? The whole point of a general-purpose database is to allow multiple applications to use the same data. Consider an online ordering system for merchandise. There's an service for checking product availability. There's a servi…

In this case I think it's proper to consider the database as a service in its own right. This is the way it always used to be done, and there are significant advantages, such as being able to focus on safeguarding the data, and leveraging ACID and constraints/stored procs to make the application code less error-prone. The downside is you have a potentially hard scalability ceiling, and you have coupling of every down…

Post by marcuslager » Sun, Jul 16, 2017, 4:10 AM UTC

eternalban wrote: post #90

sbov wrote: post #42

Earlier quoted context omitted.

A huge point of microservices is to create code that is independent of eachother. Your database backend is tightly coupling what should be completely independent services. Microservices were designed to scale your engineering departments just as much (if not more than) your performance. You are throwing away the major point of why microservices were created in the first place when you do what you're doing: so teams i…

> You are throwing away the major point of why microservices were created in the first place when you do what you're doing: so teams in large organizations can do independent releases. Let's ammend this: so teams in large organizations +{that lack both a coherent architecture and the ability to devise one} can do independent releases +{by adoptiong the no-architecture architecture}.

Post by maxxxxx » Sun, Jul 16, 2017, 4:50 AM UTC

mgkimsal wrote: post #92

tiziano88 wrote: post #44

Earlier quoted context omitted.

I feel 100% like you. Most developers won't think about clear interfaces between components unless they are forced to do so by an RPC layer. I think at some point we are going to realise this and step back on our footprints , ending up with a monolithic architecture with clearly defined boundaries between components enforced by expressive type systems.

> Most developers won't think about clear interfaces between components unless they are forced to do so by an RPC layer. The developers I know who can't think about clear interfaces are also the ones that won't know how to write clear RPC, and won't be able to create clean microservices.