Categories
Microservices

What are microservices? Tips for successful implementation

What are Microservices?

Software always keeps evolving, both with regards to functionality and also with regards to the architecture. A decade or so ago we had software that was built using n-tier technology, that later led to Service Oriented Architecture and now microservices. This does not mean that these technologies were inferior but rather the way we do things have changed and hence expectation.

Microservices are an evolution of service oriented architecture where the services are designed to be smaller, complex services are composed of smaller services that work cohesively together. They allow multiple language/frameworks to be used while adhering to HTTP REST.

Microservices were conceived to solve the problems associated with frequent releases. Microservices don’t need to be designed for the max capacity, since the system is composed of smaller services elastic scalability (scale on demand) can be leveraged possibly using virtualization and rapid deployment.

Microservices Architecture

microservices

The shift from monolithic architectures to more loosely coupled services is due to the challenges faced when frequent releases were being sought. Monolithic applications brought about coupling as the code base comprises of multiple horizontal and vertical layers, thus bringing about code reuse challenges too. Owing to the increased complexity of the system along with the large build/test and deployment cycles mounted to considerable lead time, this was true even for small changes as they required complete deployments.

Microservices are designed to be domain specific around problem areas referred to as bounded contexts. They can evolve independently and can be build using different architectures as long as they HTTP REST based. This allows for agility and also makes cloud native easier to implement.

Building Microservices

In contrast to monolithic systems, microservices are composed of multiple services that each represent a domain. So the first task is to identify domains, this can be done by investigating the working system and decomposing the system into smaller pieces and define relationships between these services. The guidelines for microservices design are to contain a set of related functionality with little or no cross domain operations.

Not only are microservices required to enable rapid deployments and agility, they need rapid deployments and agility to work. This is due to increased number of services that in turn need frequent deployments as they evolve independently. Test automation should accompany the deployments to quickly identify issues whenever a new deployment occurs.
With regards to designing the services, the key is also to also to provide proper versioning and the ability to function in reduced capacity when a non-critical microservice ceases. There should also be instrumentation like log aggregators and trace id implementations that lets us inspect the system as a whole.

Advantages of Microservices

Microservices don’t make traditional services obsolete, they however do try to solve a problem associated with rapid deployments and elastic scalability. The following are the few advantages

  • Microservices are protocol aware, that is they leverage HTTP REST for their communication
  • Microservices allow for heterogeneous interoperability (also referred to as polyglot development), this means one can pick their choice of programming language as far as they are leveraging HTTP REST
  • Microservices allow each unit of work to be called from other unit of work within the system, though this is an advantage sometimes guidelines need to be established to define hierarchy of invocations to prevent circular references etc.
  • Microservices enable agility and quick deployments, though they need quick deployments to be successful
  • Microservices uses distribution (network calls for all interactions) and hence scale on demand (elastic scalability) is possible by introducing microservices if the system is under load
  • Microservices present a well-defined service boundary however they should be properly versioned to allow backward and possibly forward compatibility

Disadvantages of Microservices

Microservices definitely offer a few advantages over the traditional monolithic designs. They bring about agility and scalability that the previous designs lacked, however they do bring about challenges with regards to increased complexity and the need for a robust DevOps strategy.

The following are the challenges faced, however these can be easily mitigated as seen in the next section.

  • Microservices bring about increased complexity due to the increased number of services, this aggravated when overly fine grained service decomposition are used.
  • Microservices increase deployment costs owing to increased number of services.
  • Microservices bring about increased distribution cost owing to the increased network communication between the services. This includes cost of setup and tear-down of the services too many network calls will exponentially degrade the system.
  • Microservices reduce reliability of the system owing to the increased number of services.

Recommended practices

Microservices enable us to build scalable applications however with the paradigm shift we need to adopt practices that will make the adoption successful.

There are design considerations that need to be taken when one or more services fail. The increased complexity due to the number of services need a comprehensive strategy for monitoring, deploying and test executions.

Design Considerations

  • Use circuit breaker when latency increases, prefer degraded functionality over failure
  • Use hybrid architecture (debated) using hierarchy and service based rules to dictate which services can be invoked by which.
  • Practice Domain driven design

Monitoring Microservices

The increased complexity due to number of services makes monitoring of services imperative. The agility of the services needs instrumentation like trace ids and unified log aggregators to track and monitor the system.

  • Using trace ids, unique keys are generated and the entire interaction can be traced and exception scenarios can be monitored.
  • Unified log aggregators enable us to get a dashboard view of the entire system, we can identify which service is degraded and take necessary step to either scale or rollback deployments.

Microservices Deployment

The increased complexity due to number of services bring about deployment challenges. These can be mitigated using a DevOps (continuous deployment) strategy to systemize the process.

Continuous deployment is key since the number of moving parts increases and also the frequency of deployments increases as each service evolves independently.

Testing Microservices

The increased complexity due to number of services makes it crucial that we adopt a continuous testing strategy as part of the DevOps (continuous deployment) strategy.

End-to-End and System integration tests should be run after each deployment

Conclusion

Microservices are the next iteration of Service Oriented Architecture, it emphasizes the use of HTTP REST interaction between the services and focuses on the agility of the services using a DevOps Continuous Deployment strategy.

It aims to keep agility to the forefront and allow for the services to evolve independently. The architecture accounts for multiple services to decrease reliability and hence build systems that can scale or work in an acceptable degraded fashion instead of failing.

Additional Resources

Categories
Microservices

Service Oriented Architecture vs Microservices Architecture

What is Service Oriented Architecture (SOA)?

​Service Oriented Architecture (SOA) which is a software structuring principle, the premise is that software systems are built around the concept of services these can be consumed by applications that can be independently be built around these services. Service providers published a service description that is available for consumers, consumers are able to interact with these using these descriptions (for example WSDL).

In a nutshell the goal of SOA is to decouple systems by allowing the service and client to evolve independently. By following proper versioning Services can provide newer capabilites for clients while supporting legacy clients to be operational and upgrade their capabilities based on their schedules. The follows are the attributes that SOA services adhere to

  • Boundaries are explicit
  • Service compatibility is based on policy
  • Services are autonomous
  • Services share schema and contract

SOA or Tiered Architecture

Microservices Architecture (MSA)

While SOA defines traits that Services need to adhere to the definition for Microservices are not well defined. Microservices are an evolution of SOA with the aim or creating modular services, the primary goal of Mircroservices are to evolve independently with a single application focus. An application can be composed of 100’s of Microservices, each driving an independent feature that allow them to be built on different platforms and deployed independently. Scalability is improved by allowing services to span multiple instances if the demand increases along with fault tolerance as a single service not loading will not cause the application to fail.

Microservices have gained in popularity with teams adopting Continuous Integration and Continuous Delivery, using rapid deployment techniques an application have 100’s or Microservices can have multiple deployments during the day. This is a big shift from SOA where large scale deployments were prevalent. The downsides of Microservices are that though they can be easily scaled they do have drawbacks as an in-memory function call is always less resource intensive than out-of-process component requests.

Microservice Architecture

Conclusion

SOA came about to decouple monolith applications and help usage of contracts to drive application development. This brought about the use of WSDL as a service description along with communication protocols that were standardized. This allowed for client to consume the service and also evolve at their own pace. The downsides for SOA were that deployments took longer as the size of the services grew and with a larger footprint scalability had challenges. Enter Microservices which takes advantage of the Continuous Integration and Continuous Delivery pipelines and also since they are feature focused can be scaled easier and also more fault tolerant.

Microservices vs SOA

See also

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview-microservices