Table of Content

1. Independent Deployability in a Microservices Architecture
2. Microservices Communication
3. Microservices Architecture Patterns or Styles (Method Calls)
4. Implementation Technologies—Protocols
5. Stream Processing Solutions
6. Deployment Techniques
   1. Execution Environments of Microservices
   2. Microservices Orchestration: Platforms
   3. Microservices in Spring Boot and Spring Cloud
   4. Challenges and Constraints of Microservices Architecture
   5. Benefits of Microservices Architecture
   6. Tools for Microservices Architecture
7. Public Cloud Computing
8. Microservices Architecture Key Takeaway
9. Krasamo Can Set Up Your Microservices Architecture
10. Krasamo’s Development Services

Microservices architecture refers to a collection of networked services that deploy independently, provide functionality that is aligned with business capabilities, and enable flexible scalability. Microservices are loosely coupled server apps that can work in isolation and be released on demand. Microservices are usually setup to interact with and provide well defined interfaces, allowing each Microservice to be updated without affecting other components.

Microservices should be modeled to conform and align with the business organization that they serve, establishing clear boundaries between services. Domain-driven design (DDD) can be used to align each Microservice with expertise of the organization that is serves.

Independent Deployability in a Microservices Architecture

By having business functionality and databases separated, you can make changes and deploy independently, maintaining compatibility with other components. In addition, independent internal implementation enables the interaction of business functionality with several external interfaces simultaneously, allowing for a faster adaptation of its products to users.

A microservices architecture allows making changes to single business units while keeping a cohesive functionality. On the contrary, in a monolithic approach, you would deploy all functionality together in a single process, requiring changes in other layers as well.

In a microservices architecture, components work independently and have established service boundaries, which lowers the risk of failure by isolating problems quickly.

Microservices are the best way to avoid lock-in from software vendors and scale your business—allowing the use of different technology stacks and tools to achieve performance.

Microservices are flexible and independent for making changes and deployment (loosely coupled) but require boundaries and assumptions about how to communicate and connect—a key aspect in understanding how they will impact other modules when making changes. The point is to make changes to a service cohesively (code cohesion)—without affecting other services—and then release them quickly.

Microservice boundaries are formed by carefully balancing its relationship across service boundaries (coupling) and sharing the minimum possible information among components (information hiding). Working models may have limited calls between services and are modeled according to context and the problems to solve.

Microservices interactions and dependencies of their functionality determine the level of coupling between them. Keeping collaboration to a minimum and coupling low or loose (loose coupling) is the ideal state to avoid issues with downstream or upstream services. Our teams can help you when modeling relationships between microservices.

For example, sharing information between services (such as data exchanges with synchronous calls, changes in data structures, shared databases, simultaneous data reading and writing, or sharing the same filesystem) may increase complexity.

The microservices architecture is designed to decompose services into smaller units, considering their context and logic, keeping ownership of aggregates (self-contained units) managed by one microservice. Decomposing means extracting functionality from the backend code, database, and user interface into microservices. Evaluating a decomposition approach and prioritizing which parts to extract first (to help avoid issues with complex implications) is part of our job as a technical partner.

As a technical partner, we develop communication between microservices, implementing local transactions withing the microservice boundaries, such as saga patterns and distributed transactions, that give consistency to the microservices architecture. Our developers implement sagas with choreography or orchestration approaches.

Microservices Communication

Microservices communication has a style or a mix depending on the specific operational context and needs, latency, security, and volume (payloads). Make sure you have evaluated the pros and cons of the communication styles and technologies being considered. Our teams create abstractions to reduce payloads, create data serialization, code the interfaces (method calls), and more.

• Asynchronous communication (message broker). Asynchronous communication allows the microservice to maintain several communications simultaneously. A request is sent as a message (message broker) that is kept in the queue until consumed (processed); it responds when ready and then routes a response. This allows the microservice to handle multiple requests, as long as it can associate (associated state) the request to the original sender. Managing internal communications logic requires building code.
• Synchronous communication (request–response calls). This is a two-way communication used with simple microservices that communicates (request) in the same network connection and instances that open a network connection (sends a call) directly to the microservice and waits for its response. In synchronous connections, low coupling is involved. Many simultaneous independent connections between microservices network calls could overwhelm the system, triggering issues that create congestion or failures.

Microservices Architecture Patterns or Styles (Method Calls)

• Request– The request–response pattern works by sending a request to another microservice to perform an action and then receiving a response in a synchronous or asynchronous approach. This microservices pattern is used when a response is required before further processing. There is high coupling as the sender knows the functionality of the recipient (domain coupling).
• Event-driven. Event-driven is an asynchronous interaction in which an event occurs or is emitted by a microservices that is required and will be used by another microservices. These interactions are loosely coupled (reduced interdependencies) as the emitter does not know the recipient’s intent.
• Common Data (data files–filesystem). Data warehousing and data lakes work with this pattern, pulling data from one direction to another party that reads or writes the file or database. As a result, this microservices pattern can handle large amounts of data volume and includes interoperability with legacy systems.

Implementation Technologies—Protocols

Implementing technologies for your microservices architecture requires careful observation of compatibility. Our teams prefer to implement microservices patterns that lean toward agnostic integration solutions. Our teams can assess your integration challenges and discover suitable protocols as well as supporting tools and technologies for your case. Consider the following options:

• HTTP
• Microservices API –Representational State Transfer (REST) –REST API –GraphQL –AsyncAPI
• Remote Procedure Call (RPC). RPC is a technique (framework) that allows making a local call invoked on a remote service. RPC protocols are used for data serialization and deserialization. –gRPC –SOAP
• Message Brokers (middleware). This is a mechanism that handles asynchronous events (publishing and subscribing) using middleware. –Apache Kafka. Kafka is often used for event-based interactions streaming large amounts of data in real time. –MuleSoft AnyPoint Platform –RabbitMQ –Google Cloud Pub/Sub –AmazonMQ
• Database –Apache Cassandra –MongoDB

  –ElasticSearch –Cloud SQL

• Filesystem Technology

Stream Processing Solutions

This includes streaming technology for stream-based architectures:

• Apache Flink
• Spring Framework
• Debezium
• Amazon Kinesis

Deployment Techniques

Execution Environments of Microservices

• Virtualization. Microservices are resource-intensive processes that require virtual machines to share physical hardware within multiple virtual environments and optimize resources.
• Application containerization is the packaging of software code in isolated units with all the dependencies needed to run an application in any environment.

Microservices Orchestration: Platforms

• Kubernetes. Kubernetes clusters are the best way to manage services and containerized workloads in a public cloud. –Azure Kubernetes Service (AKS) –Google Kubernetes Engine (GKE)
• Docker is an open-source containerization platform for developing, packaging, and running apps in containers (isolated environment).

Microservices in Spring Boot and Spring Cloud

Microservices can be gradually built with Spring Boot’s embedded server model using the Java programming language.

Visit the Spring Boot web page.

Challenges and Constraints of Microservices Architecture

• Must decide how to handle network failures
• Data consistency issues due to multiple processes and databases
• Latency for operations could be impacted because of high bandwidth use
• Service modeling
• Accessing data for reporting purposes
• Manage to troubleshoot
• Security of microservices endpoints
• Set up and execution of automated end-to-end testing across multiple processes
• Working on unstable business domains
• Smaller teams get overwhelmed
• Create network interactions between services
• Align organizational structure with system architecture

Benefits of Microservices Architecture

• Independent deployment leads to faster delivery
• Allows many developers to work independently and in parallel to improve delivery
• Scale services by pieces “on-demand”—a scalable architecture
• Able to isolate failure of components
• Embrace multiple technologies
• Optimal team size for high productivity
• Reuse functionality for different purposes
• Use different programming languages

Tools for Microservices Architecture

A successful microservices architecture implementation depends on your understanding of business logic and physical architecture as well as your ability to  monitor the state of the system. The following tools are some of the most-recommended for solving operational problems when working with microservices architectures.

• Log Management–Aggregation Collect and aggregate application logs from services into a live dashboard. –Cloud Logging

  –Humio –DataDog –CloudWatch

• Tracing Analysis Analyze trace data across services. –Jaeger

  –Lightstep –Honeycomb

Public Cloud Computing

Cloud computing providers service microservices architectures with managed services and options for deployment such as storage, databases, serverless computing, platforms, message brokers, and others. Microservices architecture is ideal for the public cloud, giving you more freedom and flexibility to build features for users. In addition, microservices can help leverage cloud services due to their technology-agnostic essence and their capabilities to deploy many types of services. Implementing a loosely coupled architecture benefits the cloud adoption process.

• Google Cloud
• Amazon Web Services (AWS)
• Microsoft Azure

Microservices Architecture Key Takeaway

Although implementing a microservices architecture will bring higher costs and slow you down initially, your long-term goals should be to improve the business, functionality, and profits. Also, make sure you assess your context, skillset, and technologies. Finally, a microservices architecture will allow you to adapt to new technologies and evolve in time.

Our teams at Krasamo can help analyze your business problem and assess the microservices solution to justify your company’s efforts and avoid downsides. We suggest an incremental migration from a monolith architecture to a microservices architecture.

Our team can answer your questions. For example, what are the benefits of microservices for your enterprise? How to decompose your system? How to draw boundaries? How to handle changes?

Sometimes the answer is not migrating or pursuing a microservices architecture but finding easier ways to achieve your goals. Keep your goals in mind, as well as the reasons to create microservices.

Migrating to a microservices architecture brings the flexibility to adapt to new technologies and new vendors quickly. However, we recommend you migrate gradually while aligning your teams, implementing organizational structure changes, and fine-tuning your digital transformation strategy.