We're dealing with an interesting case where being the "shiny things that solve problems I don't want to deal with" person, we are struggling to get developers who can help our team.
We're doing some accounting software, and instead of the "boring software", we chose to:
1. Use Kotlin over Java
2. Use gRPC over REST
3. Use microservices over a monolith, or 3-tier whatnot
4. Use "containers" over "Java application containers".
Firstly; for the kind of gig we're doing, we've only been able to find developers experienced with Java EE, some who've mainly used Java 6 because some of the large shops are "that behind".
We got a software architect so that I could focus on other things, and he started off by wanting to tear everything apart, and move us to "boring software".
He's had some success, but slowed us down a lot in the process. For example, he was uncomfortable with Docker or containers because in his mind, many clients still deploy GlassFish and JBoss/WildFly containers. So we were forced to get gRPC working on those application servers. He was unhappy with the idea of exposing ports (even internally) other than the standard 8080.
Then he didn't like that we were handling transactions manually, which was fine; so we moved to JPA. We implemented JPA with local resource transactions, and it was a mess trying to merge our Frankenstein with JTA transactions on the container. After we wasted a week, he conceded that we can keep local resource transactions.
He said that no client should consume RPC methods (he hadn't researched what gRPC 'solves'). So his suggestion was that we add a REST proxy on top of the gRPC endpoint that the front-end connects to. I tried explaining that the front-end already uses gRPC, but he insisted that the front-end would also have to proxy to JSON.
So, I explained that:
1. We have devs at varying levels, some beginner (because resource constraints), so Kotlin is easier than Java, to equalise the field. He was uncomfortable with mixing Kotlin with Java.
2. gRPC ensures that we have sane contracts between our services, making it easier to separate our offering into little modules. Imagine a client using SAP wanting to integrate our solution into SAP. Instead of modifying the guts, we can create a small service that connects to the API to do that. I also personally wanted type-safety, and to not deal with errors like "the date format is incorrect" (which I dealt with during the prototyping days last year).
3. Microservices; we were able to abstract our database logic away from the business rules. Yes, JPA and Hibernate handle connecting to different database types, but we wanted further separation should we ever need to build with a different datastore (unlikely, but I built the prototype in 'Record Time (TM)' with MongoDB).
4. I had a Docker Compose script for the entire thing running in under an hour (incl. Docker build etc.). I had to step in on the ops side after a month of our JBoss thing still not working.
______
So, new and shiny tech often solves certain problems that we think don't exist, but until you use the tech, you won't realise that what your "boring software" was doing was less effecient.
Ask any developer who's written Java and earnestly learnt Kotlin. Ask anyone who used to deploy the "boring" way and now used containers. Ask any integration engineer who used to parse JSON and now uses Thrift or Proto.