[bamboo_7]

I've never worked for a company that said "we are going to use technology that takes twice as long to implement new features."

Even when I worked in a boring industry like advertising and banking they expected things to be done by next sprint and were very accepting of the instability tradeoff.

I'm not saying that they're thesis is wrong: boring but stable software is a Very Good Thing, but it's not just us devs wanting to use the latest and greatest that's driving such quick tech adoptions.

[alex_duf]

I think the point is _some_ devs want the latest shiny thing in prod. So no one says "we are going to take twice as long" but "we need to use X" when maybe we don't.

I also use micro services on a daily basis, which this manifesto seems to dislike very much so I'm more of the opinion that pragmatism should be priority #1

Need micro services? good, use it

Need an ORM? why not (though use with care)

Need a relational databse ? go for it

Need noSQL? sure

Just make sure you have a good reason to pick whatever you work with, and usually the simpler the better.

They all have pros and cons and I feel this manifesto might be more of a knee jerk reaction rather than trying to solve anything

[skohan]

Yeah the anti-microservice sentiment is a bit bizarre. It almost reads like the author wants to stick with Ruby-On-Rails circa 2005 as the be-all, end-all of application architecture.

Don't get me wrong, there's such a thing as innovation for its own sake which does not add value, but there is nothing wrong with a single-page application driven by microservices. That architecture is pretty well proven and "boring" at this stage.

[sametmax]

It's not bizarre, it's experience outside of big shops.

First, you probably don't need it. There is a scale at which you benefits from microservices more than they cost. Most companies don't have that scale.

Secondly, unless you have three 10x programmers in your team, the microservice architecture is going to add a lot of complexity that will be a burden to manage.

So as usual, it's what you get VS what it costs.

Micro services are not free.

[eropple]

I would suggest that there is a nontrivial difference between a service-oriented architecture and microservices, and there can often be a lot wrong with the latter when misapplied. In smaller teams, thinking in terms of a service-oriented architecture (I prefer "product-oriented architecture", where something like a shared auth service is a product making semi-formal or formal contractual guarantees to its customers, internal or otherwise, at a business rather than a code level) tends to break up into larger pieces of functionality. You are still paying a cost for doing so, but I have found most clients to be more receptive and better able to manage, say, three of them, rather than a dozen or more.

Most teams don't have the problem that microservices actually exist to solve: a fractured org chart. Because that's when you want and need microservices--when your org chart's reporting chains are separated to the point where you need to separate functionality for human and political reasons, so as to avoid having one set of interests stomp on another. There's a geometric cost to any services; generally speaking one should be sure that the carried organizational and technical load of adding another (in the microservice-swarm pattern this load is smaller on margin but heavier in frequency, and it adds up) has positive ROI.

[s-shellfish]

It's basically boiling down all software and computer science to 'simple' versus 'complicated' but the problem is, what's simple and what's complicated is always relative to your frame of reference.

If you are used to thinking in one paradigm in a very rigid way, of course the other is going to be hard to comprehend, hard to use, challenging to implement, and difficult to maintain. That doesn't make one solution objectively better or worse. Pick the right tool for the job. Sometimes the right tool starts with the way the mind is thinking about the problem.

All of this can drive you insane to get 'perfect' especially when technology moves fast, and the world changes. So at the end of the day, 'good enough' is usually 'good enough'.

I feel like a lot of the advice out there about software and software philosophy are just venting steam sometimes, because, people who work with software and hardware often have to not only deal with a machine telling them the way they do things are wrong (like an error message, or just trying to figure out how to make the thing do what it's supposed to do) but also plenty of people around them, saying "this is the right way to do things". Yes, it is the right way to do things, sometimes.