Enterprise Microservices Design [Part 2: Inner Architecture Zone]

  1. The microservice should have a single purpose and single responsibility, and the service itself should be delivered as a self-contained unit of deployment that can create multiple instances at the runtime for scale.
  2. The microservice should have the ability to adopt an architecture that’s best suited for the capabilities it delivers and one that uses the appropriate technology.
  3. Once the monolithic services are broken down into microservices, each microservice or set of microservices should have the ability to be exposed as APIs. However, within the internal implementation, the service could adopt any suitable technology to deliver that respective business capability by implementing the business requirement. To do this, the enterprise may want to consider something like Swagger to define the API specification or API definition of a particular microservice, and the microservice can use this as the point of interaction. This is referred to as an API-first approach in microservice development.
  4. With units of deployment, there may be options, such as self-contained deployable artifacts bundled in hypervisor-based images, or container images, which are generally the more popular option.
  5. The enterprise needs to leverage analytics to refine the microservice, as well as to provision for recovery in the event the service fails. To this end, the enterprise can incorporate the use of metrics and monitoring to support this evolutionary aspect of the microservice.
  6. Even though the microservice paradigm itself enables the enterprise to have multiple or polyglot implementations for its microservices, the use of best practices and standards is essential for maintaining consistency and ensuring that the solution follows common enterprise architecture principles. This is not to say that polyglot opportunities should not be completely vetoed; rather they need to be governed when used.

2.1 Identifying Microservices

General Guidelines to Identify Microservices

  1. Start by analyzing the business domain to understand the application’s functional requirements. The output of this step is an informal description of the domain, which can be refined into a more formal set of domain models.
  2. Next, define the bounded contexts of the domain. Each bounded context contains a domain model that represents a particular subdomain of the larger application.
  3. Within a bounded context, apply tactical DDD patterns to define entities, aggregates, and domain services.
  4. Use the results from the previous step to identify the microservices in your application.
Sample : Boundary Context to Microservices Identification

2.2 Microservices Implementation

  1. Identifying Storage Requirements
  2. Identify Microservices communication
  3. API Design
  4. Class Design
  5. Implementation
  6. Testing

2.2.1 Identifying Storage

General Guidelines to Managing Data

  • Identify the type of Data (relational, non-relational, object) and use the appropriate storage mechanism
  • Embrace eventual consistency wherever possible.
  • When you need strong consistency guarantees, one service may represent the source of truth for a given entity, which is exposed through an API.
  • For transactions, use patterns such as Scheduler Agent Supervisor and Compensating Transaction to keep data consistent across several services
  • Store only the data that a service needs. A service might only need a subset of information about a domain entity.
  • If two services are continually exchanging information with each other, resulting in chatty APIs, you may need to redraw your service boundaries, by merging two services or refactoring their functionality.

2.2.2 Identifying Microservices Communication

  1. East-West: In this type of communication, microservices communicate with other microservices within the Inner Architecture zone of the enterprise
  2. North-South: In this type of communication, microservices communicate with External Architecture zone services

General Guidelines for Microservices communication

  • Identify all the services the microservices needs to communicate
  • Identify and document the communication protocol
  • Identify and document the API request and response structure
  • Create a sequence diagram of the necessary behavior

Mock Services

2.2.3 API Design

General Guidelines for API Design

  • REST APIs should accept JSON for request payload and also send responses to JSON. JSON is the standard for transferring data.
  • We shouldn’t use verbs in our endpoint paths. Instead, we should use the nouns which represent the entity that the endpoint that we’re retrieving or manipulating as the pathname.
    Example: /books
  • The action should be indicated by the HTTP request method that we’re making. The most common methods include GET, POST, PUT, and DELETE. GET retrieves resources. POST submits new data to the server. PUT updates existing data. DELETE removes data. The verbs map to the CRUD operations.
  • To eliminate confusion for API users when an error occurs, we should handle errors gracefully and return HTTP response codes that indicate what kind of error occurred.
  • Most communication between client and server should be secure since we often send and receive private information.
  • We should have different versions of API if we’re making any changes to them that may break clients.

2.2.4 Class Design

2.2.5 Implementation

2.2.6 Testing

  1. Unit testing
  2. API testing
  3. End to end testing

2.2.7 Versioning

2.2.8 Best Practices

  • Receive a request object from the service layer
  • Convert the request object from the service layer to Client Request Object
  • Send the client request object to the external client and receive the client response object
  • Convert the client response object to facade response object
  • send the facade response object to service layer

What’s Next?

--

--

--

Certified cloud architect having nine (9) plus years of experience with proven expertise in formulating architectural solutions for an enterprise

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Writing architecture dossiers with markdown in a git repository to make it an effective artefact

Why You Will Always Be a Script Kiddie… And Why That’s a GOOD Thing.

INTRODUCTION OF HELM

Era Swap Users | Mission & Vision

Part 3: Pen Test DropBox — Adding a Cellar Backlink

Serializing Data in a Rails App

Viewing I.T. Operations with a Developer Mindset Tripled My Salary

Best Lean Manufacturing Tools and Techniques

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ravikiran Butti

Ravikiran Butti

Certified cloud architect having nine (9) plus years of experience with proven expertise in formulating architectural solutions for an enterprise

More from Medium

All things microservices (Part II)

What are Microservices ?

Design patterns for Microservices.

Design Patterns And Design Principles Notes