Home Audience Developers A Few Best Practices For Design And Implementation Of Microservices

A Few Best Practices For Design And Implementation Of Microservices


By embracing microservices and implementing the recommended best practices and tools, organisations can unlock agility, scalability, and innovation, paving the way for a successful digital transformation journey.

Today’s enterprises are undergoing digital transformation by adopting a variety of technologies. IoT, smart devices, analytics, mobility, and even social media are helping companies change their customer relationships, internal processes and value propositions. Microservices can accelerate this transformation, but implementing the right architecture may seem challenging. Fortunately, these potential barriers can be overcome by adopting several best practices.

Many organisations have key business functionalities fulfilled by a single, large ‘monolithic’ application — for example, a CRM. By having functionality encapsulated in one application, the company’s architecture is unable to provide the agility or scalability required to achieve digital transformation.

In contrast, a microservices architecture uses granular, distributed services with well-defined APIs based on domain-driven design. This structure promises improved agility, scalability, reliability, and a reduced time to market. Organisations that use microservices as a building block for their distributed enterprise systems can augment and aggregate existing functionality as a service, thus opening opportunities for new business models and revenue.
In addition, organisations must chalk-out a clearly defined foundation and design strategy for their microservice adoption. By following the best practices, they will be well on their way toward realising the many benefits microservices can offer and achieving their vision of digital transformation.

Drivers for microservices adoption

The main drivers for microservices architecture adoption by businesses are:

  • The organisation’s primary business revolves around extremely high volume transactions
  • Rapid development requiring enhanced operational support
  • The need to reduce implementation and release cycle time and enable continuous delivery
  • Organisations migrating from monolithic and legacy processes to microservices
  • Scalability and flexibility of cloud services to handle more customers simultaneously without interrupting service
  • Solutions that require the integration of business capability from disparate systems and programming models
  • The need to align business and IT functionality
  • Business and technology agility
  • Better ROI
  • The need for incremental development (Agile) and continuous deployment of business software

Benefits of microservices adoption

Microservices are built using lightweight frameworks and open source technologies. They offer a quick time to market and many other benefits too.

  • Improve fault isolation; larger applications can remain largely unaffected by the failure of a single module.
  • Provide business agility and support continuous delivery. New functionality can be added easily and quickly. Development teams work independently.
  • Eliminate long-term commitment to a single technology stack; develop the code independently using whatever technology the developer feels is right for delivering business function. Different parts of systems can use different technology stacks if needed for better performance. Technology heterogeneity or polyglot programming is one essential benefit of microservices.
  • Microservices make it easier for a new developer to understand the functionality of a service.
  • Smaller codebases help developers focus and have a higher empathic relationship with the users of their product, leading to better motivation and clarity in their work.
  • Ease of deployment; one part of the system can move to another machine or to another cloud while the rest of the service can stay on-premise.

Best practices for the design and implementation of microservices

No legacy system can be transformed into microservices overnight. Organisations that want to introduce microservices must decide where and how these can be integrated into their existing applications. The first step is to define the microservices architecture. It has to be established how the services will interact with each other before a company attempts to optimise their implementation. Once microservices architecture gets going, we must be able to optimise the increase in speed.

It is better to start with a few coarse-grained but self-contained services. Fine graining can happen as the implementation matures over time. The developers, operations team, and testing fraternity may have extensive experience in monoliths, but a microservices-based system is a new reality; hence, they need time to cope with this new shift. Do not discard the monolithic application immediately. Instead, have it co-exist with the new microservices, and iteratively deprecate similar functionalities in the monolithic application.

This is not easy and requires a significant investment in people and processes to get started. As with any technology, it is always better to avoid the big bang approach, and identify ways to get the toes wet before diving in head first.

Always adopt automated toolsets that need to be added to the stack. Granular monitoring, log aggregation and dashboard, application metrics, automated deployment and system dashboard need to be addressed as part of the automated toolset.

The best practices for designing and implementing microservices are briefly listed below.

Business capability based design: Microservices architecture typically needs teams that specialise in business capabilities with different requirements, such as order approval, shipping, delivery and returns management, which are all part of order fulfilment. Companies should aim to focus not on more projects, but on products. Services should be developed as independent products that are well documented and each is only responsible for a single business capability.

New features: Identify new features that must be added to the monolithic application and develop them instead as microservices. Alternatively, if new features cannot be identified, it is desirable to replace features in the monolithic application that are ‘less critical’ and more ‘self-contained’.

New microservice: Agree on a standard interface for communication between the monolithic application and the new microservice. The new microservice needs to be self-contained, and hence, has to have its own runtime environment. The service also needs to be deployed on a separate infrastructure that is isolated, either physically or logically, from the monolithic application.

Granularity: Agree on building coarse-grained services that are more actively or frequently used, rather than a bunch of fine-grained services. The coarse-grained services will lead to fewer network calls being made between the monolithic application and the microservices.

Separate data store for each microservice: Do not use the same data store for all microservices. Each microservices team should select the database that is best suited to its service. A single data store also holds a significant risk that microservices from different teams share the same database structures, perhaps to avoid duplicating work. When one team updates its database structure, other services that use the same structure may also have to be adapted.

Code maturity: All code in a microservice should have a similar degree of maturity and stability. To add or rewrite the code that works well in a microservice, the best way is usually to create a new one for the new or altered code and leave the existing microservice where it is. This helps to iteratively release and test the new code until it is error-free and maximally efficient.

Deployment in containers: Deploying microservices in containers is important; you need one tool to deliver everything. As long as the microservice is in a container, the tool knows how to deliver it. Docker has currently become the standard for containers.

Monitoring: Use logs such as Splunk and monitoring tools like AppDynamics to measure efficiently and simply with mechanisms such as response time notifications, service error notifications and dashboards.

Tools and frameworks for microservices adoption

There exist various tools and frameworks for the development of microservices across the organisation. The major activities of microservices development are:

  • API management
  • Messaging
  • Data storage
  • DevOps
  • Service mesh
  • Monitoring
  • Microservices management
  • Security
  • Web application development

The various features that need to be addressed as part of the microservices development are:

  • Load balancing
  • Event sourcing
  • Asynchronous messaging
  • Service discovery
  • Service monitoring
  • Proxy server
  • NoSQL
  • CQRS
  • CI/CD
  • Persistency
  • Data provisioning
  • Error handling
  • API design
  • API analytics
  • API gateway
  • API management
  • Authentication
  • Container management

Figure 1 summarises the tools and frameworks that need to be adopted in design to deploy the microservices based on open source technologies.

Open source microservices tools and frameworks
Figure 1: Open source microservices tools and frameworks

The following are some of the key open source microservices tools and frameworks.

Chef: Chef is an open source automation platform that transforms infrastructure into code. It operates in the cloud, on-premises, or in a hybrid environment. The Chef development kit provides the tools to develop and test infrastructure automation code from the local workstation prior to deploying changes into production.

Docker: Docker is software used for OS level virtualisation. It is used to create, deploy, and run application packages called containers. Containers allow the developer to package an application with all the parts it needs, such as libraries and other dependencies, and ship it as one package. Docker is lightweight, open and secure.

GitHub: This collaborative code review tool supports around 200 software languages. It also supports all the version control features of check-in, commits, branches, merging, labels, task management, wikis, push and pull to/from GitHub, etc. Git fits in very well as a popular and distributed version control system for teams located at different geographical locations.

OpenShift: This is Red Hat’s cloud computing PaaS offering. It is an application platform in the cloud, where application developers and teams can build, test, deploy and run their applications.

Jenkins: Jenkins is a cloud based continuous integration tool that helps to automate the activities of build, code analysis and storing the artefacts. These activities are triggered once a developer or the team commits the code to version control repository.

Jenkins has many plugins and works as a CI tool for various technologies like C/C++, Java/J2EE, .NET, Angular JS, etc. It also provides plugins to integrate with SonarQube for code review, JFrog Artifactory for storing binary artefacts, testing tools like Selenium, etc, as a part of the automation process.

Kubernetes: Open source Kubernetes is free and downloaded from its repository on GitHub. Administrators must build and deploy the Kubernetes release to a local system or cluster or to a system or cluster in a public cloud, such as AWS, Google Cloud Platform (GCP) or Microsoft Azure.

Gravitee.io: This is an open source platform for managing APIs that are flexible and lightweight. It offers out-of-the-box features such as rate limiting, IP filtering, cross-origin resource sharing, plug-and-play options, open source API developer portal with OAuth2 and JSON web tokens policies, and load balancing.

Tyk.io: This open source API gateway has been developed in Go programming language. It provides an open source API developer portal, detailed documentation, a dashboard for API analytics, rate limiting for APIs, authentication, and various other such specifications that help organisations focus on microservices environments and containerisation.

Swagger Hub: This open source API management platform renders a wide range of options to designers and developers in the backend development domain. It provides a robust and intuitive editor that delivers higher efficiency and speed while preserving design consistency.

MongoDB: This is a powerful, flexible, document-oriented and scalable NoSQL database. It supports features like indexes, range queries, sorting, aggregations and geospatial indexes. It supports JSON to store and transmit information. JSON, being standard protocol, is a great advantage for both the Web and the database. MongoDB supports a rich query language to support read and write operations (CRUD) as well as data aggregation, text search and geospatial queries.

Proper implementation of microservices makes the oganisation agile to changes in business and boosts time to market. The cost and time to develop and deliver applications reduces to a large extent, and systems become more resilient. Microservices bring a change in organisation communication that allows development and operations teams to formulate, strategise, and deliver in more efficient ways.

Open source tools, patterns, processes, and people play a crucial role in implementing microservices properly. These help the team to develop and manage microservices efficiently. Tools cut across design, development, deployment, tracing and monitoring. As the number of microservices grows, tools that use automation will be necessary to manage them. New processes like continuous integration and delivery, and decentralised governance need to be put in place to enable frequent releases using the microservices platform.

Finally, avoid creating too many microservices. Every new microservice uses multiple resources. Split larger services into microservices only when the demand is for scaling, life cycle, or data. Making them too small transfers complexity from the microservices into the service integration task. Also, avoid sharing microservices between systems.

Previous articlePopular Frameworks for Developing Web-Based Chatbots and Virtual Assistants
Next articleMojo With Impressive Speed, Yet Cautious At Open Source Front
The author is an Enterprise Architect in BTIS, Enterprise Architecture Division of HCL Technologies Ltd.  Has 28 Years of experience in architecture and design, which includes Digital Transformation and Enterprise Architecture with key focus on IT Strategy, Application Portfolio Rationalization, Application Modernization, Cloud Migration, M&A, Business Process Management, Cloud Native Architectures, Architecture Assurance, Connected Intelligence, Trust, and Realization. Brings a global perspective through his experience of working in large, cross-cultural organizations, and geographies such as US, Europe, UK, and APAC.



Please enter your comment!
Please enter your name here