Skip to content

Instantly share code, notes, and snippets.

@codesword

codesword/microservices.md

Last active August 21, 2016 22:30
Show Gist options
  • Save codesword/a9de203af0f11d2af0f55b38c0767c28 to your computer and use it in GitHub Desktop.
Save codesword/a9de203af0f11d2af0f55b38c0767c28 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
microservices.md

You asked a lot of question here. Let me aswer them one after the other.

  • What are they? - microservice as an 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. Check out this link for more info.

  • What are the upsides of making use of microservices? - their upside include:

    • Large applications are splitted into smaller manageable services which are easy to understand, modify and re-write.
    • Easy to deploy and test each service since it's small.
    • New developers can easily make sense of a small microservice and start contributing immediately unlike a large monolith with millions of lines of code.
    • A microservice can be scaled based on it's needs which might be higher CPU power, bigger memory etc. The whole monolith will need to be scaled even if the performance bottleneck is coming from one small specific section
    • Different small teams can work on different microservices and iterate quickly as against having one large team working on a monolith.
    • Each microservice can be written in any language best suited for it. You can also try out new and interesting languages/technology when building/rewriting a microservice. In essence, it eliminates any long-term commitment to a technology stack(we can decide tomorrow to rebuild some of our javascript microservice using python or elixir or haskell)

  • What are the downsides of making use of microservices? - their downside include:

    • Complexities moves from each microservice to their interaction
    • You have to deal with the complexities of distributed systems(trust me, this is a whole new world)
    • Testing microservices as a whole is very difficult(how do you test 50 services working together?)
    • It's very cumbersome to start a new app using microservices architectural style. Infact, it's not advisable because elaborate distributed architecture will slow down development.
    • You have multiple point of failure which should be worried about.
    • Monitoring becomes extremely important. That's the only way you can truely figure out what's wrong with your system.
    • You have to worry about inter-service communications, retrieving records that spans multiple services, asynchronous request, distributed tracing, implementing circuit breaker to take care of unresponsive services, service coordination, etc

  • What can be used in place of micoservices - You can replace microservices with the following

    • Traditional monolith.
    • Traditional monolith that has different modules talking to each other.
    • Traditional N tier architectures(layered applications). An app can be divided into presentation layer, business logic layer, data access layer, validation layer etc. These layers can be different applications/project which combine to give you one large appliation.

  • What have they come to replace? They have come to replace traditional Service oriented architectures(SOA) which has been around for a very long time. You can say microservices is a subset of SOA for the modern era. In SOA,

    • Boundaries are explicit
    • Services are autonomous
    • Services share schema and contract, not class
    • Service compatibility is based on policy.

    Microservice fulfill all of these while allowing services to communicate with each other using HTTP REST as against SOAP. Microservices are built in a distributed fashion taking advantage of the cloud to easily scale horizontally.

  • When is it appropriate to use microservices instead of other available option(s)?

    • When your codebase grows very large and too many people are working on the same codebase. Things becomes messy and harder to manage.
    • When you have new developers coming and leaving a large application.
    • When you fully understand your business and know what you want(not when building out a new product)
    • When it becomes hard to scale due to too much traffic.

    These are the popular ones, sometimes the need can be specific to the company. For example, in andela's case, the reasons were:

    • We have a lot of applications that needs to share data(skilltree, kaizen, proctoc, andelabs, pulse etc). These required us to write a bunch of hooks in each app that can be called from other apps to get data and update their database.
    • We want technology department to be a place were fellows can learn different technologies and languages. Having a monolith won't give us that freedom. We want fellows to be able to get hands on engineering experience on the different tracks(js, ruby, python, java, php) we support .Also, say tomorrow, we start receiving request for Scala developers, we can decide to build new/rebuild existing microservices using scala so that fellows can get the experience working on scala.
    • Each team can iterate quickly and easily without holding back. Microservices makes it possible. We currently have 4 teams working independently. This number is expected to increase really fast.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment