Microservices, APIs, SOA


I found a great article on "Microservices, SOA, and APIs: Friends or enemies?"
check it out.. really easy to understand the differences

https://developer.ibm.com/tutorials/1601_clark-trs/


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.
https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/

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?

Benefits

  • Scalability:
  • 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.

Disadvantages

  • 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

https://12factor.net/

  • 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]