Recently microservices are getting popular in the Java world. So I, too, have started to hype microservices as a clever way to manage the complexity of huge applications. The general idea is that our applications have become too complex. Better split them into smaller chunks, small enough to swallow for a small team or even an individual. They have "to be small enough to fit in your head".
Actually, this idea is far from being new. When functions, classes, modules, portlets, SOA services and business processes were invented, people used pretty much the same words to advocate the new idea. Microservices add a new twist in that they optionally contain the GUI, and in that every microservice uses it's own database or it's own backend. The application is sliced vertically (as opposed to the horizontal slicing imposed by the MVC model).
The result is a small library that can be deployed independently from the other parts of the application. The application consists of a collection of largely independent microservices working together. This means you gain a lot of flexibility. Different parts of the application can be developed at different speeds. You also get the freedom to experiment. Individual microservices can be deployed and undeployed quickly, so you can afford to deploy a microservice features a new concept and see what happens. If it doesn't work out, you simply replace it with the previous version.
By the way, it's a funny observation that something called microservice tends to be bigger than a SOA service. The term "microservice" is misleading: such a service can consist of several hundred classes. There's no clear definition of what a microservice is or how big it may be. I know of two rules of thumb: "it has to fit into my head" and the two-pizza-rule. A microservice team has to be small enough to be able to get full from two pizzas. I'm told American pizzas are bigger than European pizzas, so obviously European microservices are smaller than American microservices. Be that as it may: the bottom line is microservices are a lot smaller than the entire application because this ensures they are easier to write and cheaper to maintain (which in term requires the microservice to be simple to understand).
Micheal Feathers wrote an interesting article expressing some of the point that make me skeptical, too. Cutting an application both vertically and horizontally is a good idea, no doubt about that. But then, that's the idea of portlets - and hardly anybody doubts portlets are a failed idea. So I suppose people will run into the same problems we already experienced with portals. First of all, your customer doesn't order a microservice. They order an application. The word "monolith" that's dreaded by architects has a very positive air from the customers perspective. Mind you, even developers prefer monoliths over lightweight services when it comes to doing the daily work. Can you remember the days when you started an editor, closed it, ran the compiler, waited until it completed, ran the linker and even started the debugger as a separate tool? Today you've got your IDE, and most developers I know prefer IDEs over individual tools. If you're really into microservices, you'd have to dislike IDEs, too.
Business applications are similar. In most cases people want to connect different parts of the applications tightly. Many applications can be cut nicely into different domains, but the domains aren't really independent of each other. They are connected. So microservices have to communicate with each other.
Let's try to find an entity we can turn into a microservice. My former boss asked me to write a microservice dealing with postal addresses. It's so tempting: addresses are standardized items. There's even a DIN norm. So why don't you create a service providing the GUI and the database of the address?
The ugly truth is there's no such thing as a standardized address. Every address is slightly different. Company addresses look different than addresses of human beings, there are PO boxes, there are addresses without a street name or without house number and so on. It's possible to create a common data structure. SAP does so, and they pay a big price for it. Or rather, they make their customers pay that price. But the bottom line is it's not enough to define a microservice able to deal with addresses. You have to embed it into a context. The address service usually has to be part of a bigger GUI, and it has to exchange its data with the surrounding microservice.
That's why the portlet idea failed. Portlets aren't intended to communicate with each other. Inter-portlet communication has been added as an afterthought, and there's no official way to jump from one dialog of your application to another. Let alone to embed a portlet into another portlet, such as embedding the address portlet into the customer portlet.
Luckily there's no such constraint on microservices. But you still have to implement the communication between services. That's not a big deal as long you've got only a handful of microservices. However, on the long run, you'll notice you've got the same level of complexity in your software as before. It simply has moved to the service communication layer.
I suspect there's a certain level of complexity you can't get rid of. Microservices are a good idea (at least if your application consists of several, largely independent parts), but you shouldn't expect them to be a silver bullet. In particular, the idea to slice the GUI of your application into several, independently deployable units adds a new level of complexity. As long as the application fits into your head, you're probably better off without microservices.
By the way, currently (April 2016) we're investigating alternative concepts in our company. API gateways look promising. So does a four-layer architecture, that adds a "delivery layer" to decouple backend services (which tend to evolve very slowly) from the front-end tier of your application. We also explore how to integrate many small apps (basically microservices with a UI) so seamlessly that it's just one single big application from the user's perspective. Other promising concepts are CAFA and BFF (Backends for Frontends).
It seems the IT industry recently hit another barrier of complexity. The huge number of new concepts indicate that the size of the average application has reached a level requiring new concepts to allow us to manage their complexity.
Microservices - a reality check
Micheal Feathers on microservices and macro complexity