Microservices Decoded: Best Practices and Stacks
Microservices Decoded: Best Practices and Stacks
An explanation of microservice architectures compared to monolith architectures, and a list of best practices and stacks that they're well-suited for.
Join the DZone community and get the full member experience.Join For Free
As modern cloud technology advances its role in mission critical business initiatives, software businesses and SaaS organizations are increasingly challenging software development professionals with creating and maintaining dynamically scalable, highly available cloud-based software. In response to these challenges engineering teams have innovated and developed creative application architectures and delivery solutions. One of the more recent trends in cloud software is microservice architecture. This innovative solution involves creating modular, independent, low-risk, highly scalable software entitles. All of this is in an effort to: modularize a software product, increase the availability of cloud hosted software solutions (through elastic scaling), limit the risk of component failures by separating concerns, and avoid big-bang software releases by decoupling dependencies into logical entities. A microservice in practice is simply dividing a software solution into logical independent factions.
The microservice architecture and modularity concept stands in stark contrast to traditional monolithic software development paradigms, where applications and services are created built and delivered as a unified solution. However the microservice concept creates business value by limiting risk and paving the way for software development teams to create and release small independent software solutions. Each modular software entity created using the microservice architecture would be limited in scope to single task or function and implemented with that goal in mind. In comparison the more traditional monolithic solutions intertwine dependencies and couples business logic with data layers. To better clarify this concept the illustration below provides a high-level side-by-side comparison of a microservice architecture against the more traditional monolithic system.
While the terminology surrounding microservices is modern within the software engineering landscape the general concept and goals surrounding the microservice architecture has been around for quite sometime. Earlier incarnations of microservice concepts were aptly titled 'Service Oriented Architecture' (SOA), however this term was too broad in scope and specific implementation strategies were vague. As such some organizations struggled to implement service oriented architecture based solutions effectively.
Characteristics of a Microservice
Clarity within software engineering field surrounding microservice architecture is currently a bit ambiguous. This is a result of the immaturity of the architecture itself and lack of industry agreed upon conventions. As microservice solutions gain notoriety the more refined, low-level definitions and specification criteria will also inherently evolve. Until these definitions and specifications mature we will can analyze and identify a number of generally accepted characteristics surrounding microservices based on pioneers who have implemented scaled and functioning microservice solutions.
Based on research, a microservice should inherently have the following characteristics:
- A small and singularly deployable entity, which can be deployed quickly with no risk to adjacent services.
- Be based on modular design patterns, which provides or consumes an interfaces related to a single responsibility.
- Have the ability to scale up easily (redundancy).
- Have a modular data layer, which is not visible to outside entities directly. (Where applicable)
- Provide a well-formed communication apparatus. Preferably through a REST API, or Message Queuing service.
- Have a clearly defined owner and deployment pipeline.
- Utilize client-based load-balancers where possible in an effort to reduce load.
Based on research, a microservice should NOT be:
- A monolithic set of inter-dependent components.
- An openly accessible database consumable by any outside entity. Data layers should be abstracted through API's where possible.
- Time consuming to deploy.
- Risky to deploy.
- A single point of failure.
Microservice Friendly Technology Stacks
As the trend surrounding building, releasing, and delivering microservices continues to grow, new technologies and platforms will naturally evolve to assist. That being said there are a number of highly valuable resources presently available to assist with microservice architecture and delivery. Below is a list of widely recognized solutions.
- Docker - http://www.docker.io
- Amazon Web Services (AWS) - http://amazon.com
- Parana - http://github.com/netflix/Parana
- Eureka (Service Discovery) - netflix
Common Gotchas and Best Practices in Working With Microservice Solutions
Architecting, implementing and maintaining microservices can quickly consume precious human and infrastructure resources if not managed correctly. When implementing a microservice-based solution it is important encourage good practices that will keep the systems and solutions flexible, efficient and scalable. This includes applying appropriate checks and balances to avoid performance issues, resource bottlenecks, and service/support bottlenecks or operations nightmares. Let's take a look at some best practices and red flags to keep an eye on.
- Avoid traffic congestion by leveraging request caching for highly utilized microservices.
- Implement and adhere to DevOps cultural practices. Development resources will need own their changes all the way to prod and support them when they die.
- Pass data via http headers where possible to reduce traffic congestions between microservices.
- Implement circuit breakers and automatic retries to help make the systems more fault tolerant.
- Use a message queuing service such as RabbitMQ, OpenMQ, etc. where possible.
- Async everything possible to improve performance.
- Implement access restriction protocols to reduce availability of the microservice to those who should not be calling it.
- Use service discovery solutions to allow your microservice architecture dynamically expand and contract without a central governing agent.
- Expect the unexpected.
In software engineering component modularization has been a hot button issue for many years. The most recent of this concept is the incarnation and definition of microservices, which indemnify modularized components. As software matures creating any logically componentized entities, which help alleviate a monolithic dinosaur approach to software development and delivery is a welcome innovation.
Opinions expressed by DZone contributors are their own.