Implementing microservice as part of architectural transformation.

Introduction:

What are Microservices (MS)?– Any guesses? As the name suggests, any business requirement that can be broken into a “Micro” level and implemented as a “Service” accessible by any 3rd party or technology / functional layers can be treated as MS.

A typical MS example heard is a layered cake. If you slice one (logical) piece out of that cake, that layered component is a complete cake-like MS conceptually.

Eligibility:

If your current system or application falls in any of the below categories, then it is eligible for upgradation or migration to the MS model:

  • Monolithic
  • Old legacy technology stacks
  • Heavy / decoupled business logic layer
  • Performance bottlenecks
  • Scalability issue
  • High Maintenance cost
  • High feature release cycles from Dev to Prod

Pros/Cons:

Below are the Pros of moving to the MS model:

  • Simple to deploy
  • Easy to understand
  • Reusable
  • Faster defect fixing
  • Minimized risk of changes

Below are the Cons of using the MS model:

  • Increase in Testing complexity due to distributed deployment model
  • Fault tolerance, latency due to multiple MS
  • For complex enterprise applications, integration & management can be a bit complex
  • Complex Use cases design & implementation can be tough
  • Communication between the MSs

Monolithic to Microservice Architecture Implementation

In the early ’90s, most legacy applications were developed using the Monolithic Architecture approach. They had benefits such as easy maintenance, easy skillset availability, and standard NFR requirements. However, business needs/demands have changed drastically over the last few years. Productivity & efficiency has taken the front seat, focusing more on DevOps and SecDevOps. Customers started seeing the benefits of moving to Microservices-based architecture, which helps them save Opex cost (and ZERO Downtime).

Architecture

Implementation Approach

Generally, each business functionality is broken down into a single (small) independent code, MS. Currently, all the enterprises are focusing on migrating or upgrading their current backend layer. As this will be a small piece of code, if there are any failures, errors, or defects, only that business flow will be impacted (rather than the complete website).

The prerequisites for finalizing the implementation approach are a robust design approach. The logical/functional design needs to be mapped as per business requirements to be easy to trace, maintain & enhance in the future.

Architecture

Implementation Challenges

Below are a few of the critical challenges being faced while implementing MS-based architecture:

  • Integration testing
  • Monitoring
  • Cyclic dependencies
  • Managing Microservices
  • Complex team communications
  • Complex business system communications

The Conclusion

MS should be used wisely based on the various parameters discussed above. MS has many benefits for DevOps communities, which own development & operation cycles. Are they the best choice for massive, complex enterprise applications? That is still under debate.

Most industries are going ahead, taking a “baby step” approach, which helps them gauge the pros/cons of the MS model as per their business requirements (and various other factors such as time to market, operational cost, etc.). But from what we have gathered and understood, it is worth your consideration and time.

Subscribe to our email Newsletter

Popular Posts

About the Author

profile image

Vaibhav Mandrawadker

Director-Client Services, Cloud ADM - App Dev

How Can We Help You?

Back to Top ↑