[aserafini]

Your reversions resonate with me very strongly, even down to the exact tech choices. While the industry seems to chase ever increasing complexity, I believe 90% of web applications would be served more than adequately by jQuery, intercoolerjs and Django running in a single container that can scale horizontally if necessary on Elasticbeanstalk. (eb deploy.. Done).

But, sadly, it feels like openly selling yourself as a consultant in these technologies would be a form of sabotage and limit your opportunities considerably.

I've just had an idea for branding myself: artisinal, vintage web development using traditional jQuery / Django. :)

[mpfundstein]

I might agree with you and your parent. My objection would be that I all too often experienced that seemingly small projects turned out to grow into huge applications. And previously accumulated tech debt is hard to get rid off. So I mostly start out now with my own boilerplates. React + Redux is one git clone command. Docker including Service Discovery (Traefic, Registrator), RabbitMQ and MongoDB is another git clone [1]. So I am productive immediately and the right tech is in place.

Regarding the discussion Micro-Service vs Monoliths. I agree that a monoliths gets you started quicker. But it also asks a lot of discipline from the programmers. E.g. 'stick to your domain boundaries', 'Don't take that shortcut of direct db access because business needed the feature yesterday', etc. Otherwise you'll have big troubles splitting it up later on. [2].

I REALLY REALLY REALLY like that micro-services make your boundaries explicit and enforce you to write contractual APIs aka Interfaces. Much more than all the promises of scalability etc.

[1] https://github.com/MarkusPfundstein/microservice-service-dis... [2] https://martinfowler.com/bliki/MonolithFirst.html

[sheraz]

Question - how long does it take for your projects to “grow into” the stack and complexity you have scaffolded up around it?

[mpfundstein]

If I look at the last two, it was 6 month and 9 month. The first one was initially thought to be just another search engine for some of the company's content. Then it got transformed into the main data store including CMS and all those nicetees. In the end, 7 people worked on it. The second one was a tool used only internally by my customer's employees. They then sold the idea to some of their customers and it had to transform into a full fledged product. 4 people are now in charge of it.

I am still coming back to projects sometimes where I didn't do this and I hate every minute hacking on them -.- 'Wish I would have just used React or whatever' are often my thoughts then :-)

[mattmanser]

How are those big projects? Why would you need any scalability for that?

From what you just said they're running for, at most, a few thousand people.

In terms of loads/numbers/etc. that's child's play and definitely not "huge applications". The kind of decisions he's talking about are for things with thousands of concurrent users per second, not per day.

That kind of stuff could be dealt with a single desktop computer running PHP and mysql. And you definitely don't need microservices.

In my experience, having worked in both enterprise and consumer startups, enterprise is shallow but broad with little need for any of the complicated stuff and more need to make the code really simple, obvious and uncomplex because it ends up dealing with so many different problems, while consumer scale is where you start needing to get a bit fancy purely because of scale, but it only deals with a couple of problems.

[mpfundstein]

To quote myself regarding micro-services: "I REALLY REALLY REALLY like that micro-services make your boundaries explicit and enforce you to write contractual APIs aka Interfaces. Much more than all the promises of scalability etc."

With huge applications, I mean 10s of thousands of lines of code with features added on a daily basis by multiple developers.

What both have in common is that they started us as seemingly small 'throwaway tools' but grew into business scale applications that serve now a core purpose.

Btw, who said I didn't use MySQL and PHP ? :D

[mattmanser]

Again, "10s of thousands" of lines of code is nothing. It's a few months work.

Introducing microservices into a small code base feels like it would be counter-productive. It adds a ton of unnecessary complexity to a tiny code base.

You don't want contractual APIs for code like that, as it grows the contracts are going to be constantly breaking as new features are added and the only people who care are the other, internal, developers.

If you used a statically typed language, in a monolith it would tell you immediately that it had happened as soon as you did your sync (which should be happening multiple times a day for everyone). Better still, the other developer would have had to deal with it, the only code you'd need to worry about is the new code you added, and again, your check in would break the build.

Code how you want, but my mind boggles at people doing microservices for tiny code bases. Much better to have a monolith until you get into the million of lines.

I am just thankful I work on statically typed monoliths where my tools just deal with it and I don't have to spend time setting up and debugging microservices instead of doing actual work.

[acheron]

Calling jquery “vintage” is like playing Coldplay on the oldies station.

[sheraz]

Sure, but there is a bit of relativism here, isn't there? A 10 year-old might consider Coldplay an oldie the same way a fresh javascript developer might consider jquery old legacy stuff despite the fact that both continue to make releases.

[sheraz]

I think if you are selling services as a consultant then perhaps sell the solution rather than the technology behind it.

When I buy a car I’m buying the benefit of it, which is convenient transportation. I don’t really think that I’m buying a drive train, engine, steel body, airbags and whatnot.