As somebody who's actually paid to implement devops practices for many clients at scale, this is nuts. The only performance argument for a service-oriented architecture (and let's be really real, the overhead of HTTP means that microservices rarely have a performance argument at all) is when and only when you have specific requirements that cannot be solved by horizontally scaling a monolithic system. Until you have an actual, metrically verified demonstration of the failure of horizontally scaling your monolithic architecture, sticking with it will in almost every instance outperform your "microservice architecture". Reliability, too, is a joke argument; building a single application (whether or not you internally segment the code with an eye towards later service segmentation) means that you have N instances of every component, rather than N of some, M of others, and so on. And nothing related to deploying your very bloggable microservice should differ from a reasonably developed monolithic system in the first place.

The set of companies that have any sort of reliability or performance-oriented need a "microservice architecture" is three, maybe four orders of magnitude smaller than the set of companies building web applications. They--and you--have been sold on a trend that is actively antithetical to the goals of delivering a product.

Build your application. Use an auto-scaling group and an ELB. You have more important things to do until you reach the scale where you can pay someone (hi) to do them.