Microservices antipatterns

Takeaways from microservice antipatterns:

  1. Overzeal­ous Services – don’t go straight into microservices, (fol­low­ing the hype per­haps?) rather than start­ing with the sim­plest thing possible. Instead, you should start by doing the sim­plest thing pos­si­ble, iden­tify the hotspots as they become appar­ent and then extract them into microservices. Start with monolith.
  2. Schemas Every­where – avoid having a shared data­base between dif­fer­ent ser­vices. This cre­ates tight cou­pling between the ser­vices and means you can’t deploy the microservices inde­pen­dently if it breaks the shared schema. Any schema updates will force you to update other microservices too. Instead, every ser­vice should have its own data­base, and when you want data from another ser­vice you go through its API rather than reach­ing into its data­base and help yourself. Use semantic versioning.
  3. Spiky Load between Services – You often get spiky traf­fic between ser­vices, and a com­mon solu­tion is to amor­tise the load by using queues between the services. Use rabbitmq.com, redis, etc.
  4. Hard­coded IPs and Ports – One solu­tion would be to use a dis­cov­ery ser­vice such as con­sul or etcd, and there’s also Netflix’s eureka. Another solu­tion is to use a cen­tralised router. Both solu­tions require reg­is­tra­tion and dereg­is­tra­tion, and both require high avail­abil­ity and scalability.
  5. Dog­piles – If one of your ser­vices is under load or mal­func­tion­ing, and all your other ser­vices keep retry­ing their failed calls, then the prob­lem would be com­pounded and mag­ni­fied by the addi­tional load from these retries. The solu­tion here is to have expo­nen­tial back­off and imple­ment the cir­cuit breaker pattern. Many libraries such as Netflix’s Hys­trix and Polly for .Net are available. You can even use the ser­vice dis­cov­ery layer to help prop­a­gate the mes­sage to all your ser­vices that a cir­cuit has been tripped (i.e. a ser­vice is struggling).
  6. Debug­ging Hell – Debug­ging is always a huge issue in micro-service archi­tec­tures. E.g., a nested ser­vice call fails and you can’t cor­re­late it back to a request com­ing from the user. One solu­tion is to use cor­re­la­tion IDs. When a request comes in, you assign the request with a cor­re­la­tion ID and pass it on to other ser­vices in the HTTP request header. Every ser­vice would do the same and pass the cor­re­la­tion ID it receives in the incom­ing HTTP header in any out-going requests. When­ever you log a mes­sage, be sure to include this cor­re­la­tion ID in the log line.
  7. Miss­ing Mock Servers – When you have a ser­vice that other teams depend on, each of these teams would have to mock and stub your ser­vice in order to test their own services. A good step in the right direc­tion is for you to own a mock ser­vice and pro­vide it to con­sumers.  You can take it a step fur­ther, by build­ing the mock ser­vice into the client so you don’t even have to main­tain a mock ser­vice any­more. Use Any­point Plat­form or Swagger.
  8. Fly­ing Blind – There are more than a hand­ful of tools avail­able in this space. There are com­mer­cial tools (some with free tiers) such as NewRelic and Stack­Driver (now inte­grated into Google AppEn­gin), AWS also offers Cloud­Watch as part of its ecosys­tem. In the open source space, Net­flix has been lead­ing the way with Hys­trix and  some­thing even more excit­ing.

Links:

 

Microservices into C# World ?

A bit of background about microservices via Martin Fowler. Some really cool stuff regarding patterns via Microservices.io.

Microphone allows you to run self hosting services using either WebApi or NancyFx ontop of a Consul.io cluster.
You can find the code here https://github.com/rogeralsing/Microphone

Consul is a system that does service discovery, configuration management, and health checking for your services. Services can register themselves using either a REST API or via DNS, and if a service becomes unresponsive, Consul can mark this service as unavailable and not include it in any search results.

You can start consul service with below line on console:

Check service health on Consul agent:

Check all services registered on Consul agent:

Discovery service output:

Time to play with some code.

Reference: Microservices discovery for .net

Microservices

Intro

Back in the day most systems started as a monolithic system, which basically means the entire application exists in a single code base and is deployed and, importantly, scaled as a single unit.

A monolithic application puts all its functionality into a single process… and scales by replicating the monolith on multiple servers. A monolithic application is harder to scale, as one small change must be deployed across all processes.

What are microservices ?

According to wikipedia, microservices are a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task, facilitating a modular approach to system-building.

Software developer advocates James Lewis and Martin Fowler gave the best definition we could find for this increasingly popular architectural pattern:

“The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”

A microservices architecture puts each element of functionality into a separate service…and scales by distributing these services across servers, replicating as needed.

Characteristics of microservices

  • Small with a single responsibility
  • Each application does one thing
  • Small enough to fit your head – If a class is bigger than by head then it is too big
  • Small enough that you can throw them away – Rewrite over Maintain
  • Status aware and Auto scaling – multiple consumers (Competing Consumers pattern example
  • WatchDog process to monitor app-status (expose metrics about itself eg: queue dept) auto-scale to meet throughput requirements.
  • A single capability composed of a small number of activities and exposing a uniform interface (REST)
  • Each is entirely decoupled from it’s clients, scalable, testable and deployable individually.

How does a microservice outshine a monolith?

  1. It makes your app more scalable with smaller teams.
  2. Enables modularity and is more open to change in general.
  3. Uses a smaller codebase.

What are microservice architecture’s limitations?

  1. It can cause communication problems among different parts of the app and within your team.
  2. It requires increased effort later on to catalog, test, and fix incompatibilities.
  3. You should still build the monolith before building the microservices on top of it.