Need for delivering new features quicker

In a competitive market where software is ubiquitous, businesses are realizing that success depends on being able to deliver good quality software at a fast pace. There are various practices and development methodologies that facilitate efficient delivery of software. The drawbacks of a traditional monolith prevent it from meeting the demands of complex large-scale applications, which require rolling releases at a fast pace.

Microservice architecture, meanwhile, promotes small modules focused towards business capabilities that can be independently deployed as services. These smaller services can subsequently be combined together to act as one large enterprise-level application. The communication between the services can happen using HTTP or messaging, which is a typical choice for lightweight communication. Successful microservice architecture is best achieved with a small cross-functional team, as it aids in delivering solutions faster. By keeping the code base small, it's often easier for the team to perform a refactor or rewrite from scratch, if the situation so demands; this wouldn't be feasible in a monolith application. The services are built as a separate application and interface with each other via published service contracts. Thus, it is easier to change the implementation details of a service without impacting other services, as long as the contract is honored.

In the case of the issue management system, we would decompose the application by breaking it into smaller services focused around a business capability. This process is known as functional decomposition.

This would create a logical isolation for each service, which will have its own database, potentially different from others such as relational or NoSQL as per the need of that service. This is called polyglot persistence, which here means allowing your service to embrace the persistence solution that is right for its needs. The impact of one service choosing a different data-store is confined to that service itself, as none of the other services are affected by this choice.

Here's how that would look in the microservices world:

It's also possible, if not mandatory, to use container based solutions to deploy these services. Container solutions such as Docker are the means to meet DevOps standards for consistent and fast deployments. There are benefits to be gained when using this architecture, such as:

• Ability to scale inpidual components/services.
• Small business capability focused services are easier to maintain and refactor.
• Business logic is confined to the context of a service and not spread across the whole application.
• Deploying a single service need not require testing the entire application.
• Each service can be allocated an appropriate server instance as per its memory or CPU needs. For example, a service such as audit could be CPU intensive, while the tickets service may be memory intensive.
• Production issues can be delegated to the right people, by knowing which cross-functional team owns the service.
• Since it's easy to deploy a single service with negligible impact to other services, production fixes and changes can be rolled out faster.

When working with a microservice architecture, tooling becomes an essential ingredient for success. Thus, it also promotes the adoption of DevOps practices such as:

• Continuous Deployment:
  • Automated deployments are a must. Imagine having to deploy 20 or 100 services manually!
  • Unit/integration testing automation to allow for faster feedback on builds.
• Automated Infrastructure:
  • Tooling for logging, monitoring, performance metrics
  • Quick provisioning and de-provisioning of instances

This approach solves many of the scalability issues inherent in a monolith, but for it to be effectively implemented, we need to look at how teams are structured. Switching to a microservices architecture will require the creation of a cross-functional team that owns a product (not project) focused towards the business need and adopting the DevOps methodology. DevOps can be considered as a cultural change, an extension of agile development practices. It tries to bridge the gap between the developers who build the software and the IT operations that maintain it. This culture promotes teams to own the build, test, and deploy cycle for the product they are responsible for delivering.