Overview of Microservices Architecture

By April 15, 2021 Powerlearnings

Compiled by Kiran Kumar, Business analyst at Powerup Cloud Technologies

Contributor Agnel Bankien, Head – Marketing at Powerup Cloud Technologies

Summary

Microservices architecture is majorly favored for distributed systems. Microservices are successors to a monolithic architecture where applications are loosely incorporated and are fragmented into smaller components that run on individual processes. 

Businesses that grow with time are obligated to revamp their framework that caters to frequent code change, application updates, facilitating real-time communication and managing rising network traffic to name some.

The challenges and benefits of building microservices architecture along with how it can actually impact business is what we will explore in this blog. 

Index

1. What is Microservices Architecture?

2. Why Microservices Architecture?

3. Evolution of Microservices Architecture 

4. Fundamentals to a successful Microservices Design      

4.2 Cohesion and Coupling

4.3 Unique Means of Identification

4.4 API Integration

4.5 Data Storage Segregation

4.6 Traffic Management

4.7 Automating Processes

4.8 Isolated Database Tables

4.9 Constant Monitoring

5. Key Challenges in Microservices

    5.1 Being Equipped for Speedy Provisioning and Deployment

    5.2 Execute Powerful Monitoring Controls

    5.3 Incorporate DevOps Culture

    5.4 Provision Accurate Testing Capabilities

    5.5 Design for Failure

6. Benefits of Microservices Architecture 

      6.1 Increased Elasticity

      6.2 Better Scalability

      6.3 Right Tools for the Right Task

      6.4 Faster Time to Market

      6.5 Easy Maintenance

      6.6 Improved ROI and Reduced TCO

      6.7 Continuous Delivery

7. Building Microservices Architecture

8. Microservices Best Practices

9. How can Microservices add Value to Organizations?

10. Conclusion 

1. What is Microservices Architecture?

Microservices or microservices architecture is a service-oriented architecture built from a collection of divergent smaller services that run independent of each other. Here applications are loosely incorporated and have fragmented components running in individual processes. Each independent service can be updated, scaled up or taken down without interrupting other services in the application.

Microservices makes applications highly maintainable, testable, and transformable, generating a scalable and distributed framework that can be built to boost business capabilities. It comprises fine-grained services with ethereal protocols that increase flexibility and modernize the business technology stack.

Microservices enable speedy, reliable and continuous deployment and delivery of huge complex applications.

2. Why Microservices Architecture?

Updating or reconfiguring traditional monolithic applications involve expensive, time-consuming and inconvenient processes. With microservices architecture, it is simpler to work with independent applications that can run on its own in different programming languages and on multiple platforms. Once executed or updated, these minute components could be grouped together and delivered as a complete monolithic app.

Thus, teams could function in smaller, independent and agile groups instead of being a part of larger impenetrable projects. One microservices can communicate with other available microservices uninterruptedly even when failures occur.

Any enterprise that uses applications needing repeated updates, faces dynamic traffic on their network or requires near real-time information exchange can benefit from adapting to microservices architecture. For instance, social media platforms like Twitter and Instagram, retailers like Amazon, media platforms like Netflix, and services like Uber use microservices, setting new standards for container technology.

3. Evolution of Microservices Architecture 

Monolithic

Initially, monolithic applications consisted of the presentation, application and database layers that were built and located on a solo data center. Users would talk to the presentation layer that in turn interacted with the business logic layer and database layers, after which information would travel back up the stack to the end user. 

However, this structured process did generate multiple single points of failure, long outages due to system failures or crashes and did not accommodate auto-fixing of errors and scaling on existing setup.

SOA

A few years down the line, architectural changes gave birth to service-oriented architecture (SOA) where a service is independently made available to other application modules via a network protocol. The approach enabled shorter autonomous development cycles via APIs but overcoming the complexity of testing integrated services along with too many failed and expensive implementations gave it a substandard reputation.

Microservices

Today, cloud microservices have the ability to further decompose the SOA strategy facilitating speedy code updates for a single function that is part of a larger service or application, such as data search or logging function. This technique enables making changes or updates without affecting the rest of the microservices, thus increasing flexibility, providing automated self-healing capabilities, minimizing failure points and creating a more stable application architecture. 

As per latest reports, 58% of enterprises run or plan to run between 10-49 microservices in production, and 15% run or plan to run more than 100.

Microservices architectures use Docker containers that are a grouping construct, more efficient that VMs. They allow the code and its required libraries to be deployed on any operating systems and can be launched or redeployed instantly on any cloud platforms. Many organizations are mirroring their systems as that on cloud microservices to enable unique development operations across any location or cloud-native setup.

4. Fundamentals to a Successful Microservice Design 

For microservices to fit into well-defined distributed application architecture, it is vital that the following elements are taken into consideration first.

4.1 Right Scoping the Functionality

Microservices enable a functionality to be partitioned into smaller micro services attributing it as an independent software component. Over-segregating the functionality would lead to excess microservices and hence it is imperative to identify which functionalities on the monolithic app are frequently called for by multiple functions. Once identified, that function can be broken down into its own service to serve diverse situations without overloads. 

Mirroring an entire module if it is not dependent on other modules within the application is also another method of scoping functionality. For example, authentication groups that manage user identity and authorization can be scoped and built as a microservice.

While defining the scope, it is best to limit the size of microservices to the lines of code (LOC) that can be re-implemented on a periodic basis in order to avoid overloads and bloating of services.

4.2 Cohesion and Coupling

A loosely coupled system has low interdependence and therefore enables deployment, edit or update of a new service without disturbing other existing services present. 

It is also vital to combine related code or homogeneous functions while partitioning a monolithic architecture into smaller services also known as cohesion. Higher cohesions mean greater autonomy leading to better microservices architecture. 

4.3 Unique Means of Identification

In a microservice design, any one particular service needs to act as a unique source of identification for the remaining parts of the system. For instance, once we place an order on flipkart, a unique order ID is generated and as a microservice, this order ID is the only source of information that provides all the details about the order placed. 

4.4 API Integration

For the broken down micro services to communicate, relate and work together it is fundamental to use appropriate APIs that enable convenient communication between the service and the client calls aiding transition and execution of functions.

Defining the business domain while creating an API will ease the process of singularizing the functionality. However as individual services evolve, richer APIs may have to be created with additional functionalities that need to be revealed alongside the old API. API changes must be fully incorporated to ensure the service behind the API is expatiated and it is able to manage the calls from multiple client types.  

4.5 Data Storage Segregation

Data stored and accessed for a service should be owned by that service and can be shared only through an API ensuring minimized dependency and access among services. Data classification should be based on the users, which can be achieved through the Command and Query Responsibility Segregation (CQRS).

4.6 Traffic Management

Once services are able to call each other via APIs, it is necessary to gauge the traffic to different services. It may vary due to slow movement or overload of calls to a service that may even cause a system crash. To manage and smoothen traffic flows, auto scaling must be implemented. It has the ability to terminate instances that cause delays or affect performance; it can track services continually and furnishes incomplete data in case of broken call or unresponsive services. 

4.7 Automating Processes

Independently designed microservices function by themselves and automation would further allow sustained self-deployment. Functional services progress to become more adaptable and cloud-native with the competence to be deployed in any environment and DevOps plays a major role in the evolution of such services.

4.8 Isolated Database Tables

Designing a microservice must cater to business functions rather than the database and its working as accessing and fetching data from a full fledged database is time consuming and unnecessary. Therefore, a microservice design should have a minimum number of tables with a focus only around business.

4.9 Constant Monitoring

The smaller components of microservices architecture with its data layers and caching may enhance performance of an application but monitoring all the changes in such a setup becomes challenging. It is vital to establish intent monitoring of data via microservice monitoring tools that will track individual services and eventually combine data to store it in a central location. Thus, any changes can be reflected without affecting the performance of the system. 

Processes must also be defined to monitor API performance to ensure the functionality meets the standards of speed, responsiveness and overall performance.

Most of all, building a well-designed secure software code and architecture from the inception phase ensures accountability, validation, data integrity, and privacy as well as safe accessibility to sturdy and protected systems.

The patterns to secure microservices architecture are:

  • Introduce security into software design from the start
  • Scan all the dependencies
  • Use HTTPS even for static sites to ensure data privacy and integrity
  • Authorize identity of users via access tokens for a secure server-to-server communication
  • Use encryption
  • Monitor systems especially while executing CI/CD pipelines through DevSecOps initiatives
  • Implement strategies in the code to limit network traffic and consecutively delay or avert attackers
  • Tool Docker Rootless Mode to safeguard sensitive data
  • As docker containers are integral to microservices, scan them for vulnerabilities 
  • Use time-based security through multi-factor authentication and network traffic controllers
  • Know the 4C’s of cloud-native security – code, container, cluster, and cloud.

5. Key Challenges in Microservices

Microservices are favorable but not every business is capable of adapting to it. Some organizational reservations are:

5.1 Being Equipped for Speedy Provisioning and Deployment

Microservices demand instant server provisioning and new application and service deployments. Organizations need to keep pace and be well furnished with high-speed development and delivery mechanisms. 

5.2 Execute Powerful Monitoring Controls

With microservices functioning independently, enterprises need to administer efficient monitoring of various teams working concurrently on different microservices as well as the infrastructure to keep track of failures and down time.

5.3 Incorporate DevOps Culture

Unlike the traditional setup, DevOps ensures everyone is responsible for everything. The cross-functional teams need to collaboratively work towards developing functionalities, provisioning services, managing operations and remediating failures. 

5.4 Provision Accurate Testing Capabilities

Since each service has its own dependencies and as new features get added, new dependencies arise making it difficult to keep a check on the changes. The complexity increases also with the rise in the number of services. Implementing flexible and penetrative tests to detect database errors, network latency, caching issues or service unavailability on microservices is a must. 

5.5 Design for Failure

Designing for system downtime, slow service and unexpected responses is essential. Being prepared for load balancing, setting up back up plans and ensuring failures do not bring the entire system to a halt helps businesses handle failures or issues better. 

6. Benefits of Microservices Architecture 

6.1 Increased Elasticity

Due to the distributed and granular structure of services, a minimal impact is experienced even in case of failures using microservices. The entire application is disseminated and even when multiple services are grounded for maintenance, the end-users would not be affected. 

6.2 Better Scalability

Scaling up a single function or service that is crucial to business without disturbing the application as a whole increases availability and performance.

 6.3 Right Tools for the Right Task

With microservices there is flexibility in terms of services using its own language and framework without being confined to a specific vendor. The freedom of being able to choose the right tool for the right task that smoothens communication with other services is a significant gain. 

6.4 Faster Time to Market

As microservices have loosely coupled services, code development or modification can be constricted to relevant services instead of rewriting the code for the entire application. Therefore, working in smaller independent increments leads to swifter testing and deployment, enabling services to reach the markets faster.

 6.5 Easy Maintenance

Debugging, testing and maintaining applications are easier with microservices. With smaller modules being continuously tested and delivered, the services become more enhanced and error-free. 

 6.6 Improved ROI and Reduced TCO

Microservices allows optimization of resources as multiple teams work on independent services, enabling quicker deployment, code reuse and reduction in development time. Decoupling cuts down on infrastructure costs and minimizes downtime resulting in improved ROI.

 6.7 Continuous Delivery

Code can be modified, updated, tested and deployed at any given point in time and released as small packets of code using continuous integration / continuous delivery (CI/CD).

After adopting microservices architecture, organizations have reported a 64% improvement in the scalability of applications, experienced 60% faster time to market, increased application flexibility by almost 50% and given their development teams 54% more autonomy.

7. Building Microservices Architecture

Step 1:

Monolith architecture is the traditional method of building and deploying software applications. As businesses grow, the list of key business capabilities to be provided by existing systems also expands.

Microservices work best if the roles of different services required by the system are correctly identified without which redefining service interactions, APIs and data structures in microservices proves costly. Adopting microservices after business has matured and gained sufficient feedback from customers is the best-case scenario.

However, it is advisable to switch to microservices before the code gets too complicated on the monolithic setup. It is important to determine and break the services into smaller pieces, separate the code from the web UI ensuring it interacts with the database via APIs. This warrants smooth transition to microservices especially when organizations would look at moving more API resources to different services in the future.

Step 2:

Microservices is not just about splitting the code, accommodating for failures, recovering from network issues or dealing with service load monitoring. It is equally crucial to reorganize teams, preferably in small numbers who have the required competency to develop and maintain microservices architecture.

Werner Vogels, CTO at Amazon quotes, “you build it, you run it” implying that developers can analyze the impact of their code in production, work on reducing risks and eventually deliver better releases. Also, multiple teams can work collaboratively on code upgrades and automation of deployment pipeline.                                                                                         

Step 3:

Once the service boundaries and teams are established, the traditional architecture can be broken to create microservices. Communication between services must be via simple APIs to avoid the components from being tightly integrated. Using basic message queuing services and transmitting messages over the network without much complexity works best in microservices.

Moreover, it is suitable to divide data in dissociated services as each service can have its own data store to carry on with what it needs. Example; suppose a user accesses customer information from the “order” table, which is also used by the billing system to generate invoice details. With microservices, invoices can still be accessed even if the ordering system is down as it allows streamlining of invoice tables that is independent of others. 

However, to eliminate duplicate data in different databases, businesses can adopt an event-driven architecture to help data syncing across multiple services. For instance; when a customer updates his personal information, an event is triggered by the account service to update billing and delivery tracking services as well.

While transitioning from the monolithic architecture, ensure designs are built for failure right from the beginning. As the system is now distributed, multiple points of failure can arise and microservices needs to address and remediate not just individual service related issues but also system failures and slower network responses if any.

Since microservices are distributed by nature, it is challenging to monitor or log individual services. Centralized logging service that adds logs from each service instance can be accessed through available standard tools right from the beginning. Likewise, CPU and memory usage can also be collated and stored centrally.

With an increasing number of services getting deployed multiple times, it is most advantageous to regulate continuous delivery. Practicing continuous integration and delivery will assure that each service has passed the acceptance tests, there is minimal risk of failure and a robust system with superior quality of releases is being built with time. 

8. Microservices Best Practices

  • Microservices should have a single-responsibility principle, which states that every service module must have responsibility for a single part of that functionality.
  • Customize the database storage and infrastructure exclusively for microservices needs and other microservices can call for the same data through APIs.
  • Use asynchronous communication or events between microservices to avoid building tightly coupled components. 
  • Employ circuit breakers to achieve fault tolerance, speed up responses, and timeout external calls when delayed. It helps isolate the failing services keeping microservices in good health.
  • Proxy microservices requests through an API Gateway instead of directly calling for the service. This enables more layers of protection, traffic control, and rejection of unauthorized requests to microservices.
  • Ensure your API changes are backward compatible by conducting contract testing for APIs on behalf of end-users, which allows applications to get into production at a faster rate. 
  • Version your microservices with each change and customers can choose to use the new version as per their convenience. Support for older versions of microservices would continue for a limited timeframe.
  • While hosting microservices, create a dedicated infrastructure by setting apart the microservices infrastructure from other components to achieve error isolation and enhanced performance.
  • Microservices must have their own separate release detached from other components.
  • Build standards within the organization for multiple teams to develop and release microservices on the same lines. Create enterprise solutions for API security; log aggregation, monitoring, API documentation, secrets management, config management, and distributed tracing. 

9. How can Microservices add Value to Organizations? 

Advancing user preferences are driving organizations to adapt to digital agility.

A survey on digital transformation by Bernd Rücker revealed that 63% of the 354 questioned enterprises were looking into microservices because they wanted to improve employee efficiency, customer experience and optimize tools and infrastructure costs. 

Netflix was one of the pioneers of microservices almost a decade ago with other companies like Amazon, Uber and eBay joining the trend. Former CTO of eBay, Steve Fisher, stated that as of today, eBay utilizes more than 1000 services that include front-end services to send API calls and back-end services to execute tasks. 

It is easier for business capabilities to get aligned with the fragmented parts of microservices as it facilitates application development to align directly with functionalities prioritized by business value. This ensures businesses are highly available, become more resilient and structured. 

Businesses can look towards scalability of applications backed by a team of experts and advanced technology, deployment becomes easier due to independent manageability and enterprises become better equipped to handle dynamic market conditions as well as meet growing customer needs. The business value proposition must be the key drivers to embracing microservices architecture.

10. Conclusion

Microservices are beneficial not just technically for code development process but also strategic to overall business maturity. Despite being considered complex, microservices provide businesses the capability and flexibility to cater to frequent functional and operational changes making them the most sought-after architectures of today.  

Its granular approach assists business communication and efficiency. Microservices are a novel concept but seem promising for the areas of application development. 

Organizations can consider microservices architecture, if best suited, to digitally transform their businesses to become more dynamic and competitive.

Leave a Reply