Important information: our Privacy Notice has been updated. To review the current Tiempo Privacy Notice and learn how we handle your Personal Data and how to contact us, please read our privacy policy here.

    Microservices - Migration and Architecture Decoupling Services


    What are microservices?

    If you are familiar with microservices and are trying to determine if this architecture is the right choice, start with our article on why companies should choose microservices.

    A microservices architecture involves the building of modules that address a specific task or business objective. As a result, these modules tend to exhibit low coupling and high cohesion. A microservice architecture is often achieved by decoupling a monolithic application into independent modules that each contain the components necessary to execute a single business function. These services typically communicate with each other using language agnostic API’s such as REST.

    Microservices were created in order to overcome the issues and constraints of monolithic applications. Monolithic applications have a tendency over time to grow in size. As applications become larger and larger, the tight coupling between components results in slower and more challenging deployments. Because of the tight coupling, the potential for a failure of the entire application due to a recently deployed feature is high. In some cases, deployments can take several months to a year, greatly reducing the number of features that can be rolled out to users. This tight coupling also makes it difficult to reuse and replace components because of the effect they may have on other components throughout the application.

    Microservices address these issues by being small in scope and modular in design. Modular design results in components being loosely coupled, which offers enormous benefits from the standpoint of being fault tolerant and independently deployable. The result is functionality that can be frequently deployed and continuously delivered. 

    characteristics of a microservices architecture

    While there is no consensus of the characteristics of a microservice architecture, there are some characteristics a microservice should have in order to achieve the benefits possible.

    • Services should communicate over the network by utilizing technology agnostic protocols.
    • Each service should be independently deployable.
    • Services should be built around business goals.
    • Services should be able to leverage polyglot programming and persistence.
    • A microservices architecture should be modular with each service being small in size and containing all the necessary components to perform its function independently.
    • The organizational culture should embrace strong Agile, DevOps and CICD practices to enable automation of testing and deployment.
    • A microservices architecture should include decentralized governance and data management.
    • Microservices are failure resistant and fault tolerant.

    Monolithic vs Service oriented vs Microservices

    When microservices first became a concept, people couldn’t help but find it difficult to distinguish the difference between microservices and service oriented architecture. While microservices and SOA architecture patterns do share a lot of similarities, there are some fundamental differences that set them apart.

    One of the biggest differentiators between monolithic, service oriented, and microservices architectures are their levels of granularity. Granularity plays an important role in software architecture. The reason for this is related to the degree of coupling and cohesion that course grained and fine grained architectures present. Coupling is the degree of interdependence between software modules. As an application’s coupling becomes tighter, the modules within an application becomes less fault resistant and more difficult to reuse. Cohesion is the degree to which the elements inside a module belong together. As a general rule, software systems should be built to be loosely-coupled and highly-cohesive. Modules that exhibit high cohesion tend to be more robust, reliable, and reusable than modules with low cohesion. Other benefits such as ease of design, ease of integration, ease of testing, ease of monitoring, and ease of deployment can be achieved with a loosely-coupled and highly-cohesive architecture. Below is a visual depicting the coarseness of monolithic, service oriented and microservice applications.

    Monolithic vs SOA vs Microservices Structure


    Monolithic applications represent the worst case scenario when considering cohesion and coupling. A monolithic application is a single-tiered architecture where multiple layers are tightly coupled and multiple components run in the same process. A single data store is utilized throughout the application. Monolithic applications also exhibit very low cohesion since the entire block of code is deployed as a unit. Monolithic architectures require the entire program to be recompiled and deployed every time a change is desired due to their inherent inter-dependencies.

    The middle ground between a monolithic and microservice architecture is a service oriented pattern. Service oriented architectures are alike to microservices in the way that modules focus on a business activity, and are much smaller in scope then an entire monolithic application. Service oriented architectures are alike with monolithic applications in that they utilize a single data store. While focused around functions, these modules are much courser grained than a microservices architecture where service components are usually single function services. Service oriented modules all communicate through an enterprise service bus. In the event of a requests backing up due to a slow service, it is possible that the enterprise serial bus could become a single point of failure that affects the entire application. As a result, service oriented architectures exhibit higher cohesion than a monolithic application, but also tighter coupling than microservices. For a more detailed analysis please read our article on microservice vs soa architectures.

    Example of Communication in Microservice, SOA, and Monolithic Architectures


    Microservices represent the loosest coupling and highest cohesion when compared to service oriented and monolithic architectures. Each service is independent in handling its function, messaging, and data storage. The primary focus of a microservices architecture is to facilitate DevOps and CICD by building autonomous and independently deployable modules.

    Comparison of Monolithic, SOA and Microservices

      Monolithic Service Oriented Microservices
    Size Highly interdependent services Smaller interdependent services Very small function-oriented independent services
    Granularity Single unit - Tightly coupled with low cohesion Moderately coupled with moderate cohesion Loosely coupled with high cohesion
    Ease of Deployment Must build and redeploy entire application Requires modifying the monolith Can independently build and deploy each service
    Remote Call Overhead Low/None communication overhead Low communication overhead High communication overhead, many remote calls
    Speed of Deployment Very slow deployment speeds Slow deployment speeds Rapid and continuous deployment
    Persistence All services in a monolithic application share data storage All services in SOA share data storage Each service is free to choose its own data storage
    Ease of On-boarding Difficult to on-board new developers Semi-difficult to on-board new developers Easy to on-board new developers
    Polyglot Programming Implement a single technology stack Can utilize different technology stacks per service Can utilize various technology stacks per service
    Communication Method Many methods exist Communicates through an enterprise service bus Communicate with lightweight protocols like REST
    Scalability Can be very challenging to scale as application becomes larger Can be challenging to scale Extremely scalable through use of containers

    Advantages of a Microservices Architecture

    Below is a high level overview, For a more detailed analysis, read our article on microservices advantages. When a microservice architecture is utilized for the right reasons, and implemented properly, they can yield enormous benefits over a monolithic architecture. The benefits that can be realized by a microservices architecture are:

    • Improved modularity results in a program that is easier to understand, develop and test. This is an enormous benefit when on-boarding new developers, as there is no need to understand the functionality of every service.
    • Enables companies to better leverage advantages of Agile, DevOps and CICD.
    • Each service can be developed and deployed independently. Being able to update a single service, or roll back a buggy update reduces risk and improves speed of deployment.
    • Each service can be written in a different programming language. This allows developers to choose a language that offers the best features for each service.
    • Each service can leverage its own database and storage techniques. Each service can have very different needs when it comes to data storage. As applications become larger and the volume of data grows, the data sets can have very different characteristics and processing requirements. Microservices allow you to choose the best data storage implementation to address the specific need of the service in order to achieve the end goal.
    • A small cross functional team can manage each service, enabling team autonomy, distributed leadership and decentralization.
    • Better able to leverage the scalability and flexibility of the cloud
    • Massive reduction in unused functionality over monolithic applications.
    • Isolating and resolving issues is much simpler as they can be isolated to a single service.
    • High degree of fault isolation. A change or failure in one service will not impact other services.

    disadvantages of a microservices architecture

    While there are several advantages to decoupling a monolithic application into microservices. There are some disadvantages that you should know about before making the switch. Most issues associated with microservices are due to the complexities introduced by a growing number of independent services. Some of the challenges that business face when utilizing a microservices architecture are:

    • While each service is easier to understand, develop, and deploy, the big picture becomes more complicated.
    • More communication is required between services. This can result in higher overhead costs associated with network congestion and latency.
    • Network security becomes increasing complex with an increasing number of microservices as communication between each service needs to be secured.
    • A strong understanding of DevOps is required in order to overcome the complexities involved with handling communication and automated deployment, testing and monitoring of microservices.

    With the right tools, processes, and preparation, the issues associated with microservices can be overcome. For a more complete analysis, here is an article on microservices disadvantages.

    When is a Microservices Architecture the Right Choice

    A microservices architecture isn’t the right choice for every organization or every application. For new applications it is often best to start with a monolithic application, and the decouple the monolith into microservices after the application concept has been proved and has grown substantially in size. The reason for this is that monolithic applications are much simpler in terms of communication, security, and monitoring complexity when compared to microservices. Monolithic applications also tend to come at a lower cost in terms of overhead and latency related to the increase in remote calls with microservices. For these reasons, start-ups should weigh the advantages and disadvantages of starting with a microservices architecture.

    Once a monolithic application has scaled and it becomes increasingly challenging and expensive to manage, scale, and deploy; a microservices architecture begins to make sense, and the advantages begin to outweigh increased complexity and overhead.

    Culture also play a huge part in determining whether an organization will achieve success with a microservices initiative. A microservices initiative will thrive in a culture that:

    Has Reached Agile Maturity

    Microservices bring a cultural shift to organizations that are organized hierarchically and with strong centralization. They share with lean thinking the emphasis on accountability, team autonomy, distributed leadership, and decentralization. You can almost entirely eliminate dependencies on the knowledge and influence of key individuals—and the bottlenecks that result when they leave or change roles—by bringing enablement and intelligence to teams of people who collaborate in a goal-driven, shared-values process.

    Embraces Continuous Deployment and DevOps

    Microservices were designed to work alongside CICD and DevOps. Because of their small size and independence, companies that utilize this architecture can benefit from deploying new features to users much faster than with monolithic and SOA patterns. To fully realize the benefits that microservices can offer and reduce the challenges associated with their increased complexity, automation of testing, monitoring, and deployment is an absolute requirement. Organizations that embrace and have a strong understanding CICD and DevOps practices are best equipped to successfully decouple their monoliths.

    Questions to Ask Before Choosing Microservices 

    • Does making small changes to my application require me to perform expensive and timely redeployment of the entire software suite?
    • Could my internal and external users benefit from features being deployed in a timelier manner?
    • Will faster deployments help us reach market faster and make us more competitive in our space?
    • Will decoupling our current application strengthen our system and result in increased reliability?
    • Does our monolithic application host a large amount of functionality that is unneeded?
    • Is our current application able to effectively utilize the scalability and flexibility offered by the cloud?
    • Do certain services need to be able to scale rapidly and on demand?
    • Could you benefit from leveraging the features of multiple programming languages for specific parts of your application?
    • Are you dealing with large amounts of data that has heterogeneous characteristics where individual services could benefit from utilizing their own data store?

    Polyglot Persistence in Microservices

    In a monolithic and SOA architecture, a single data store must be utilized across all services. Unfortunately, the large data volumes involved in larger applications feature data that have extremely varied characteristics and requirements for processing. A single data store is often not the ideal approach to structure and process all the sets of data that can be collected by an application.

    In a microservices architecture, each service is able to utilize its own data store, leaving developers free to choose the database type that best fits the characteristics and processing requirements of the service. The ability of an application to choose different database technologies for individual services is known as polyglot persistence.

    Below is an example of what data persistence looks like in a monolithic, service oriented, and microservices architectures.


    Microservices Containers and Orchestration

    Containers allow individual services to be deployed independently, and without the unnecessary requirement of having to deploy a full embedded OS as with virtual machines. With containers, services are encapsulated with a lightweight run-time environment. Each container includes everything required for the service to run. This makes containers a good fit for microservices as it increases the speed at which applications can be deployed, increases fault resistance, and enables them to work across platforms. By far the most popular tool for building, storing and running containers is Docker.

    Ok, so you have your containers. Now what? Now you will need a centralized way to efficiently arrange, coordinate and manage your services to align with business requests. This is accomplished with a container orchestration tool. These tools enable systems to scale automatically, and reduces the time required to deploy multiple instances of a single application. There are several container orchestration tools on the market. Currently, the most popular container orchestration tool is Kubernetes. Kubernetes is often used in conjunction with Docker to orchestrate Docker containers.

    we can help with your microservices migration

    Microservices do not have to be scary or challenging. Since microservices and container orchestration is so new, often times the most difficult part of a microservices migration is finding experienced talent to lead your team. A good place to start is with our article on getting started with microservices. This is where Tiempo Development can help.

    Tiempo Development has provided consultation and software development support on many clients microservices initiatives. If you are struggling with your microservice migration, or want a second opinion on your techniques and strategies, we would love the opportunity to help. Please drop us a line below, and we will contact you shortly about your microservices project. 

    Contact Us!

    Get Free Widget