Overview of Microservices Architecture in Simple Terminology

Discussion in 'Engineering Concepts' started by madhub, Jun 16, 2015.

  1. madhub

    madhub New Member

    Joined:
    Jun 16, 2015
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    0
    Microservices are:
    • Small and highly decoupled apps
    • They have a single purpose/functionality
    • Accessible via APIs
    • Microservices are self-sufficient and they do not depend on other microservices.
    • Containerless & installed as well-behaved services
    • Installed the same way you would install https or any other application
    • A microservice is independently deployable.
    • Can be deployed as an isolated service on a platform as a service (PAAS), or it might be its own operating system process.
    • Microservices could have their own databases as well.
    • Crafted to become the building blocks of larger applications.

    What is Microservices Architecture?


    • In Microservices Architecture, a software component is an independently running service that interacts with the other parts through message passing.
    • The independence of services helps with achieving high cohesion and loose coupling, which deliver all sorts of benefits (reliability, scalability, reusability, and so on).
    • Services can be redeployed with different replication and location configurations as the design of the overall system evolves.
    • Even the technology used for the implementation of a service can be changed, as long as its interface is still compatible with the rest of the system.
    • In Microservices Architecture, service boundaries should enforce separation of concerns at a business level.
    Please refer to the diagram shown below for more details:

    [​IMG]

    Why do we need it?



    From end-user’s point of view:
    • Users expect a rich, interactive and dynamic user experience on a wide variety of clients including mobile devices.
    • Applications must be highly scalable, highly available and run on cloud environments.
    • Organizations often want to frequently roll out updates, even multiple times a day. Consequently, it’s no longer adequate to develop simple, monolithic web applications that serve up HTML to desktop browsers.

    From software professional’s point of view:
    • Smaller teams working on smaller codebases tend to be more productive.
    • A small team that contains all the skills necessary to build, deploy, and manage the service creates a micro service. The team has end-to-end responsibility for the service.
    • From developer’s point of view, we can decide to use different technologies in case of a complex system rather than having to select a more standardized, one-size-fits-all approach.
    • A microservices-based architecture lends itself to a continuous delivery software development process.
    • Continuous delivery lowers both friction and risk.
    • Applications are created as a suite of services instead of one tightly coupled monolith of code. Hence it is easier to change and maintain.
    • When services are shared, redundant work can be eliminated.
    • A live service is used as part of your application. Since we are tapping its functionality via API, in case the service is improved, every application using that service can benefit.

    How is it different from Service Oriented Architecture (SOA)?


    • A service in an SOA is usually an entire software application, whereas a service in an MSA is a software component.
    • A Service-oriented architecture (SOA) aims at integrating various (business) applications whereas several microservices may belong to one application only.
    • Microservices architecture looks at services from a developer's perspective rather than an enterprise architect's perspective, so the services are finer-grained.
    • Microservices can be thought of as a specific approach for SOA. One example to understand it is just as XP or Scrum are specific approaches for Agile software development.
    • Communication among services is simpler: JSON replaces XML and REST replaces SOAP, and heavy-duty middleware is not part of the deal.
    • To build a MicroServices Architecture (MSA), developers need to be able to build independently running services, program their coordination via message passing, and manage their deployment. Handling all of these aspects is difficult already in a typical Service Oriented Architecture (SOA).

    Known uses



    Most large scale web sites including Netflix, Amazon and eBay have evolved from a monolithic architecture to microservices architecture. Netflix has developed tools and platforms such as Docker that are already popular for microservices.
    Microservices used by me:
    1. One of the most popular microservice is Jenkins CI:
      • Jenkins plays well with other services like GitHub, SVN, Git using HTTP and REST-like APIs. In fact Jenkins is very popular in non-Java environments.
      • The state is managed by each Jenkins instance individually in an own repository (JENKINS_HOME)
      • Services are exposed via Remote API
      • The UI is self-contained
      • Jenkins can be easily extended by an independent team
      • Jenkins is already packaged as a micro service: just launch the service with java -jar jenkins.war
    2. Another popular microservice which I have been using for quite some time now is the OSGi:
      • In OSGi world, the modules are called bundles. Bundles manifest their dependencies (import packages) and the packages they expose (export packages) so other bundles are able to use them.
      • OSGi runtime or container manages the bundles. In our case we use the Knopflerfish container.

    Challenges of Microservices Architecture


    • Versioning - It is very difficult to version hundreds of applications and components each relying on a bunch of other ones for delivering the required services.
    • Integration - Finding the right set of technologies for your microservices is a challenging task. Adopting a hybrid system and integrating the different services successfully is highly critical.
    • Testing – Introduce proven DevOps practices, such as continuous delivery and configuration management from the start. Automate acceptance, regression and performance testing at an early stage of development. The hardest thing in microservices architecture is not testing services individually – it is rather making sure that the whole system remains functional and coherent after every change.
    • Deployment - With microservices you are creating individual pipelines for individual components.

    Scenarios to choose Micro Services Architecture (MSA):


    • Mostly microservices are good choice for distributed applications with a need for scaling and high availability.
    • Do not create shared dependencies on artifacts that are under constant pressure to evolve such as the domain model.
    • Message passing systems use networked memory instead of shared memory.
    • Networked memory is inherently slower than shared memory but obviously this makes them highly decoupled and robust.

    References and reading materials:


     
    Last edited by a moderator: Jan 21, 2017

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice