I found a great article on "Microservices, SOA, and APIs: Friends or enemies?"
check it out.. really easy to understand the differences
A little bit about Microservices:
It's often said.. complex code is spaghetti code (with meatballs = OOP), well structured layered code is lasagne code.. and microservices ravioli code.
On bigger applications.. a well thought out monolithic modular app might not be enough or at least not performant enough.
Big companies like Netflix talk about it.
The millions of users require:
- fast startup times,
- easy and reactive ui,
- working movies (main functionality),
- no downtimes and
- always new features/updates.
The solution to this of course is a microservice application
Thoughts before creating microservice instead of monolithic applications:
- Do you need to scale? How much concurrent users do you have?
- Does your application or several parts really need to have a high-availability?
- Do you develop in separate teams or is everyone on one team?
- Microservices can be monitored really well, giving you metrics to find services with high hardware requirements or faulting services
- run multiple instances for particular services, making reaction times really fast by also giving you a high availability (in case they crash)
- You can run/scale on multiple Servers / PaaS Instances (Pivotal, AWS, ...) with different spec requirements depending on what your microservices needs
- Improved Isolation:
- every Microservice should be one logical part and thus can be updated or refactored or exchanged separate without affecting the others
- By doing only one particular job (bounded context).. your microservices become easier to read, test and optimize
- You can use multiple programming languages in one project. eg. node.js, ruby, c#, python, c, R.. in the end you talk via API
- Background Services:
- You can run background jobs, which wait for events to start working. they can do things without your interaction.
- Distributed System Complexity (Logging, Monitoring, Network, Msg Queues, Multiple Instances, )
- with more Services, more parts can fail
- Architecture causes network-load and can be slowed down by network-latency
- May have double code for same helper functionalities
Programming Services it is highly recommended to apply the principles of
12 Factor Apps
- Code is Version controlled with many deploys [Codebase]
- Dependencies are declared and isolated in a manifest [Dependencies]
- Configurations are stored in ENVironment variables, not config files [Config]
- Service are attached Resources, which can be consumed over Network (local or 3rd Party) and can be detached at will [Backing Service]
- Build and Run stages are seperated. Providing a faster, tested and better Release Management. [Build, release, run]
- Services are Stateless. They share nothing. They only use persistent data from backing stores. Thus they can easily be scaled. [Process]
- To fit the concurrency needs, services are exported via Port Binding. [Concurrency]
- Processes should be designed to be disposable without hassle [Disposable]
- You should have a similar Developement and Production environment, designed for continuous integration. [Dev/Prod parity]
- Logs should be treated as Event Streams. The App should never be concerned of storing logs. [Logs]
- Management Tasks running as Processes: no local terminal, no direct db access. [Admin processes]