Don't start with microservices – monoliths are your friend

They will figure out monolith Rails makes a lot of sense eventually. Or maybe I'm wrong who knows.

I've mixed feelings about it. As advertised it can be somewhat useful for business rules-rich apps, yes, but most of the times the application side of the project will just grow exponentially faster than your core - especially if you don't keep an eye on commits, as some of your coworkers may choose the easy way out and push business logic on the application side instead of refactoring... It's a clean architecture from a business logic standpoint, indeed, but it doesn't do a lot to keep the outside of the hexagone well organized (beside the port/adapter pattern), and that side of the app can grow into a mess really fast if your team lack experience.

Not as many abstraction layers than in a classic J2EE app, though. It's not that bad.

Microservices are supposed to be autonomous. Independent services with an own lifecycle. What this article is describing sounds more like what is called a distributed monolith. Too many horizontal dependencies will create problems no matter where they are located.

I worked on monoliths where the shortest theoretical amount of time from a commit to running in production is several hours. The way you in a controlled way can change small parts of system with microservices is incredibly useful.

What I do see though is people making microservices too small. Like one table in a monolith database becomes one microservice. Microservices is not about having everything loosely coupled. Cohesion rules for modules still applies.

Choose your architecture.

Worked with a huge monoliths, business critical, predictable usage, easy debugging, deployment simple, onboarding quick even with less documentation.

Worked with microservices, business critical, predictable usage, less documentation here onboarding took long time spent on how it works, Hard to debug, never needed to scale up. (Why microservices ? )

Lessons learnt: Problem is never with the architecture. Why you choose one over the other is the question to ask when you start on.

> ...then don't spend hundreds of thousands on infrastructure.

I find it curious how we went from doing the basics of software development that would minimize risks and be helpful to almost any project out there to this.

To clarify, i agree with the point that you'll need to prioritize different components based on what matters the most, but i don't think that you can't have a common standard set of tools and practices for all of them. Let me address all of the points with examples.

> Auth: nobody knows IP address of our server anyway, don't bother with that. And for extra security we have secret port number.

Port scanning means that none of your ports are secret.

JWT is trivial to implement in most languages. Even basic auth is better than nothing with HTTPS, you don't always need mTLS or the more complicated solutions, but you need something.

This should take a few days to a week to implement. Edit: probably a day or less if you have an easily reusable library for this.

> Monitoring? Well, we have our clients for that. They'll call us if something happens.

This is not viable if you have SLAs or just enjoy sleeping and not getting paged.

There are free monitoring solutions out there, such as Zabbix, Nagios, Prometheus & Grafana and others. Preconfigured OS templates also mean that you just need the monitoring appliance and an agent on the node you want to monitor in most cases.

This should take close to a week to implement. Edit: probably an hour or less if you already have a server up and just need to add a node.

> Deploy? Copy .war file and restart tomcat. Rollback? What's rollback?

This is an error prone way to do things, as the experience of Knight Capital showed: https://dougseven.com/2014/04/17/knightmare-a-devops-caution.... In addition, manual configuration changes lead to configuration drift and after a few years you'll have little idea about who changed what and when.

In contrast, setting up Ansible and versioning your config, as well as using containers for the actual software releases alongside fully automated CI cycles addresses all of those problems. In regards to rollbacks, if you have automated DB migrations, you might have to spend some time writing reverse migrations for all of the DDL changes.

This should take between one to two weeks to implement. Edit: probably a day or less once per project with small fixes here and there.

> Outdated packages? We call those stable packages.

Log4j might be stable, but it also leads to RCEs. This is not a good argument, at least for as long as the software packages that we use are beyond our ability to control or comprehend.

This should be a regular automated process, that alerts you about outdated and/or insecure packages, at least use npm audit or something, or proactive scanning like OpenVAS. This should take close to a week to implement.

All of the mentioned software can easily run on a single node with 2 CPU cores and about 8 GB of RAM. I know this, because i did all of the above in a project of mine (mentioned technologies might have been changed, though). Of course, doing that over N projects will probably increase the total time, especially if they have been badly written.

In my eyes that's a worthwhile investment, since when you finally have that across all of your apps, you can develop with better certainty that you won't have to stay late and deliver 2 or 3 hotfixes after your release, which goes hand in hand with test coverage and automated testing.

That is hardly hundreds of thousands of dollars/euros/whatever on infrastructure. And if the personnel costs are like that, i'd like to work over there, then.