Microservice Architecture make applications easier to build by breaking down application into services. The services are composable. Each service can be deployed and developed separately. The services can be composed into an application. The services have the possibility of being used in other applications more readily. This can speed up development as services can define an interface and then the services can be developed concurrently.
Another reason services make sense is resilience and scalability. Instead of depending on a single server and a single deployment, services can be spread around multiple machines, data centers or availability zones. If a service fails, you can start up another. Since the application is decomposed into microservices (small services), you can more efficiently scale it by spinning up more instances of the heaviest used services.
If you have lived through COM, DCOM, CORBA, EJBs, OSGi, J2EE, SOAP, SOA, DCE, etc. then you know the idea of services and components is not a new thing. The issue with enterprise components is they assume the use of hardware servers which are large monoliths and you want to run a lot of things on the same server. We have EJBs, WAR files and EAR files, and all sorts of nifty components and archives because server acquisition was a lot more difficult. Well turns out in 2015, that makes no sense. Operating systems and servers are ephemeral, virtualized resources and can be shipped like a component. We have EC2 images AMIs, OpenStack, Vagrant and Docker. The world changed. Microservice Architecture just recognize this trend so you are not developing like you did when the hardware, cloud orchestration, multi-cores, and virtualization did not exist.
You did not develop code in the 90s with punch cards. Don’t use an EAR file or a WAR file in 2015. Now you can run a JVM in a Docker image which is just a process pretending to be an OS running in an OS that could be running in the cloud which is running inside of a virtual machine which is running in Linux server that you don’t own that you share with people who you don’t know. Got a busy season? Well then, spin up 100 more server instances for a few weeks or hours. This is why you run Java microservices as standalone processes and not running inside of a Java EE container.
Microservice generally provide an API endpoint over HTTP/JSON. This allows easy integration with not only services you build, but any software (open-source or from vendor) that provides an HTTP/JSON interface. This makes the services consumable and composable in ways that just make sense. A prime example of this is EC2, S3 and other services from Amazon (and others). The very infrastructure you deploy on can become part of the application and is programmable.
When you design your application to use microservices, you are designing it to be modular, programmable and composable. This allows you to replace microservices with other microservices. You can rewrite or improve parts of your larger application without disruption. When everything has a programmable API, communications between application microservices becomes easier. (Never trust a microservice that does not publish access to with curl).
Docker and other container technologies are viewed by some as a integral to microservice architecture and some confuse and conflate containers with microservices. Containers are minimalist OS pieces to run your microservice on. Docker provides ease of development and enables easier integration testing.
Containers are just an enabler to microservices and you can do microservice development without containers. And you can use Docker to deploy monolithic application. Microservices and containers like Docker go well together. However, Microservices are a lot more than containers!
In order to actually run an application based as a number of microservices, you must master async / reactive programming, you need monitoring, you need distributed logging, health monitoring, performance/metrics monitoring, service discovery, and more. Tools like consul, etcd, SkyDNS, Mesos, ZooKeeper, Kubernetes, Spinnaker, Docker Swarm, need to be on your short list of things to learn about.