Designing Fine-grained systems – part1

Hi this is to start a new series of posts about microservices architecture, it’s going to be mainly in the format of Q/A.

In this post.

    • What’s the Microservices architecture ?
    • What are the patterns of Microservices architecture?
    • What are the benefits of Microservices architecture ?

Q:What’s the Microservices architecture ?

A: There’s no specific answer for this question however it’s generally accepted to say that it’s designing systems that are formed of many small (as in small responsibility list) and independently deployed services.

My definition: It’s a child for SOA that’s favoring distributed, single responsibility services over monolithic service(s).

This may trigger another question(s) like:

  1. How small is microservice ?
  2. How to ensure that services are independent in terms of responsibility and deployment ?

Please, check next question’s and next posts for answers.

Q:  What are the patterns of microservices architecture?

A: Following are the main patterns of what’s usually conceived to be a Microservices design:

  1. Services over libraries for components
    Instead of having systems that are formed of components that are libraries, system is now formed of small services that are often used to share code and logic between other services.
  2. Business layout over Technical layout
    For a normal eCommerce store, instead of having front-end and backend teams and components we will have:
    shopping-cart, search, collection services and teams.
  3. Automation
    “If it’s hurts, do it more often”   — Martin Fowler

    All the hurting stuff should be done more often or in other words (automated) hence things like (CI/CD, Automated Testing, Accept rewrite of components,etc..) are essentialNote: If you are resisting the fact that services should be completely rewritten in no time then services are either not small enough or it’s designed somehow to be tightly coupled to another service(s) which indicates a bad design.Hint: A good practice and well-known pattern is to have the ability to rewrite and roll-out a rewritten service in 2 weeks for example.
  4. Choreography vs imestration *
    choreography
    If you have many services this triggers a question how should you conduct some command, do you create a service that’s dedicated for orchestrating what other services should deliver ?
    Same for your team do you create a team that’s dedicated for management ?In Microservices it’s more like a ballet dance. Despite how accurate and synced are the dancers you don’t see some manager who guide dancers in execution time. This is called choreography.
    In this metaphor every dancer is a service and music is system inputs and services should react to this independently without external governance.
    Same for teams each team should be able to code, test and deploy his service independently.
    Which comes hand to hand with next pattern.
  5. Automation and monitoring.
    Infrastructure automation CI/CD are essential in microservices.
    In a system with 10s and may be 100s of services  rate of change and deployment is huge and it can’t be only Ops team responsibility in such architecture DevOps team has a main responsibility to enable automation in infrastructure.
    One of the benefits is being fault tolerance(on system level) but the failing service still need to know how did this happen, what’s the current response time what are the consumed Memory, etc..
    I can safely say that Monitoring and Automation are essential to any successful Microservices architecture.
  6. Failure Is Inevitable. What Matters Is How You Deal With It.
    Miniature-Circuit-Breaker-Application-Guide
    If a short-circuit happened in your kitchen, your laptop in living room should survive.“– Me trying to explain electrical circuit breaker to one of my friends.The lesson learnt from great electrical engineers is that you should be able to handle failure because it will happen no matter you try to avoid it and I strongly recommend reading how netflix are fault tolerant.
    Caching, retrying, rerouting are brilliant ideas for mitigating failure in runtime and this article has lots of ideas.

Q:What are the xkeybenefits of Microservices architecture ?

A:  Microservices architecture isn’t a silver bullet yet it has many advantages and to name a few:

  1. Fault Tolerance (in other words failure isolation) unlike monolithic apps there’s no single point of failure.
    Example: In e-Commerce store:  if searching service is down this doesn’t mean that the store is down, it just means you can’t search now but you still can buy, add to shopping cart, etc..
  2. No vendor lock-in or technology stack lock-in (every service can be using different stack) microservices favor hetrogenity loose coupling generally hence stack and vendor unlocking is by design.
  3. Horizontal Scalability (well, it’s the  fact that you can split your system into small services and put every service in one machine/vm/container makes it better to scale wisely)
    Let’s say that your eCommerce system is composed of shoping-cart, search-engine and catalog
    With microservices architecture every component can be a separate service and each service deployment can be scaled (up/down) based on load applied on this specific part of the system.
    On the other monolithic hand, scaling up and down is per system deployment.
    spartplug
  4. Maintainability, test-ability (inherited from being small separable services you can verify if every service can work alone and hence test it, monitor it and rewrite if you want.) What if a spark plug wasn’t removable ?
  5. Resource utilization (think of it as space utilizing problem for a jar where filling is Sand vs  small ball vs big ball.)
    the smaller the better.

*1. I’ll do another post about event-driven asynchronous programming to support this point.

Sources

      • Building Microservices: Designing Fine-Grained Systems Kindle Edition by Sam Newman
      • Microservices a definition of this new architectural term www.martinfowler.com/articles/microservices.html
      • Micro services, what even are they?

        http://rea.tech/micro-services-what-even-are-they/

      • FrequencyReducesDifficulty

        https://www.martinfowler.com/bliki/FrequencyReducesDifficulty.html

13 months of MC

It has been 13 months since I first joined MC.

I started as 13 months ago and I’m still as excited as I first joined I’m doing different things here and there and I’m now responsible for a team of 5 besides my work.

Very recently I managed to pull of a face lift for couple of our main money generating components and managed to reduce performance of both apps dramatically, unfortunately I won’t be able to share details more than having this  Selection_002change on some major app for 3 weeks in a row and that was around 300% decrease in page load time.

I was happy 1 year ago and I’m still. this is what matters after all.

Technically the major updates was taking ECMA Script and Design more seriously (Weird mix) but this is reality.

Since I’m taking architecture more serious now (both application and system architecture), I’m willing to post and talk more frequently about design in the following posts.

See you soon.

LinkedIn vs. XING [linkout gem]

I have to admit. I always didn’t like linkedIn, very bad UX and UI and features aren’t aligned enough to convince me that I should stay more than 5 minutes browsing it not to mention the absolute clutter at it’s news feed and how non-sense is it to follow and watch completely irrelevant posts and shares.

Anyway, since it’s the hub of all companies and jobs and leading(so-called) professional network I had to make a profile there and keep it updated as much as I can.

In May 2015 LinkedIn announced a change in API  they commented on this API change by saying

For many developers, we understand that today’s changes may be disappointing and disruptive, but we believe these changes will provide further clarity and focus on which types of integrations will be supported by LinkedIn.

And this year with high resolution image of Microsoft’s CEO and linkedIn’s Microsoft has acquired linkedIn

“The LinkedIn team has grown a fantastic business centered on connecting the world’s professionals,” Nadella said. “Together we can accelerate the growth of LinkedIn, as well as Microsoft Office 365 and Dynamics as we seek to empower every person and organization on the planet.”

With that said I’m expecting no good from LinkedIn anymore except for helping Microsoft be a better in monopoly.

Hence I’ve developed  linkout ruby gem to allow scraping LinkedIn profile without the need of their API.

And I’m also developing a new app that uses this gem to port your profile to XING.

I’ll update this post when this app is ready so keep an eye on it.

Note: use linkout gem only to get your profile data not to scrap the whole linkedIn or else you’ll be violating ToS of linkedIn.