[sheraz]

Yes, and I love it.

In hindsight I have been guilty of resume-padding and falling prey to hype by choosing to build on technology not appropriate to the problems at hand. And I find myself reverting back to basics, with bits of new tech sprinkled in.

My reversions:

  - React, flux, redux ---->  jQuery and intercoolerjs when needed
  - Swarm, Kubernetes  ---->  Just plain old docker on single machine, scale vertically with cores and memory when needed
  - Microservices first ----> Django Monolith first, then break out microservice when needed
  - API Gateways (kong, Azure) ----> Nginx reverse proxy with hand-edited configs.

I can do this because I have chosen to work on niche problems and smaller markets. Scale is not my issue, even in very successful scenarios.

I see jQuery will have a place in my stack for some time to come. It just works (tm), and it plays well when I need to level-up with wither intercooler or yes -- backbone.

Another benefit is that it is a low barrier to entry for junior developers. It allows me to establish a baseline knowledge, and then mentor other things like workflow, code structure, and architectural things rather than chasing weird configuration things inside of webpack or the taskrunner-du-jour.

[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

[acheron]

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

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

[joevandyk]

How do you deploy updates to the docker containers without downtime?

[xet7]

For example with Docker Swarm: http://container-solutions.com/rolling-updates-with-docker-s...

Some companies have GitLab workflows that also deploy successfull builds automatically, checks are there problems in that deploy, and rollbacks automatically when needed: https://twit.tv/shows/floss-weekly/episodes/473?autostart=fa...

Such workflows could also be made with for example: - Huginn https://github.com/huginn/huginn - Flogo http://www.flogo.io

[sheraz]

Well, the trick is that I have downtime but it last for only a few seconds.

  Docker pull <image name>
  Docker container stop <container name>
  Docker run <opts> <image name>

This does result in a “hiccup” for any clients wanting to connect. They will see a 502 gateway error at which point they should retry with exponential backoff.

And that is the trick — make the client retry with the exponential backoff. Document it as the expected behavior when that event arises. And for our traffic patterns this is acceptable.