ceracm

There is a good argument that you should just focus on the solving today's problems and building a good product, e.g. https://en.wikipedia.org/wiki/You_aren't_gonna_need_it . It is possible that the extra effort you would spend on being 'microservices ready' would slow you down too much and incur too much risk.

Having said that you could try to ensure that your system remains modular. For example, implement your business logic using loosely coupled DDD aggregates and use eventual consistency rather that ACID transactions.

The reasons are varied. Some like SQL are acronyms - structured query language. C++ because it is the successor to C. C because its the second language derived from BCPL - the first was B.

The transition from coarse-grained compute resources to fine grained resources will continue: pets (long lived, mostly physical) machines that are lovingly cared for) -> cattle (disposable, immutable VMs) -> rabbits (disposable containers) -> microbes (AWS lambda and other cloud functions). There will undoubtedly be a few surprises along the way.

It depends. There are tradeoffs - http://microservices.io/patterns/monolithic.html and http://microservices.io/patterns/microservices.html

For some applications - especially the simpler ones developed by a small team - the monolithic application is fine. But for large complex applications developed by large teams it is likely that a microservice architecture can be helpful.

Software development is a profession like any other. I am not convinced that everyone needs to know how to code.