19/180: Microservice & Architecture

Today is day 19 of 180 day’s streak, writing this blog bit late because of internet issues. This challenge I have taken to make learning as my habit.

Let’s begin:

Why Microservices?

Most Popular Architecture paradigm, but it’s never like that you have go with the famous architectures, but it all depends on type of product you are working on. It is not tied to any technology stack, you can use technology of your choice in a single product depending upon the requirements. It solve real world problems. And this is in high demand in job market.

If microservices are implemented in correctly or used as a band-aid without addressing some of the root flaws in your system you’ll be unable to do new product development because you are drowning in the complexity.

Alexender Nooman, Engineer Segment

History of Microservices

Microservices are a result of problems with two architecture Paradigm

1. Monolith
2. SOA

Monolith

1. The original architecture
2. All software components are executed in a single process.
3. No distribution of any kind
4. Strong coupling between all classes.
5. Usually implemented as Silo

Pros: Easier to design. Performance is also fine.

Service Oriented Architecture

1. Apps or Services exposing functionality to the outside world.
2. Services expose meta data to declare their functionality
3. Usually implemented using SOAP (Protocol for webservices) & WSDL
4. Usually implemented with ESB (Enterprise Service Bus)

Pros: Sharing data and functionality. Polyglot between services (Platform independent)

Problems with Monolith and SOA

1. A lot of problems were found in both paradigms. Problems relevant to technology, deployment and cost more.
2. Single technology platform: with monolith all the components must be developed using the same development platform. Not always best for the task. Can’t always use specific platform for specific feature.
3. Future upgrade is a problem, need to upgrade the whole app.
4. Inflexible deployment: new deployment is always for the whole app. No way to deploy only part of app. Even when updating one component the whole code base is deployed. Force rigorous testing for every deployment. Forces long development cycles.
5. Inefficient compute resources: Compute resources (CPU & RAM) are divided across all components. If a specific components needs more resource no way to do that.
6. The codebase is large and complex, every little change can affect other components. Testing not always detects all the bugs. Difficult to maintain. Might make the system obsolete.
7. With SOA, the ESB is one of the main component, can quickly become bloated and expensive. It tries to do everything. Difficult to maintain.
8. For SOA to be effective, short development cycles were needed to allow it for quick testing and deployment. No tooling existed so no time saving was achieved.

History

Problem with monolith & SOA led to a new paradigm. Has to be modular, with simple API. The term microservices first appeared in 2011.

Characteristics

1. Componentization via services
2. Organized around business capabilities
3. Products not projects
4. Smart Endpoints and Dumb Pipes
5. Decentralized Governance
6. Decentralized Data Management
7. Infrastructure Automation
8. Design for failure
9. Evolutionary Design

Components via services

Modular design is always a good idea. Components are parts that together compose the software. Modularity can be achieved using libraries. Libraries are called directly with in the process. Services are called by out of process mechanism (Web API, RPC). In microservices we prefer using services for the componentization. Libraries can be part of services. Motivation to do this was independent deployable and well defined interface.

Organized around Business Capabilities

Traditional projects have teams with horizontal responsibilities. UI (Team A), API (Team B), Logic (Team C), Database (Team D). Each teams we dependent on the others. The process was slow and inter-group communication also caused issues. With microservices every services is handled by single team, responsible for all aspects. UI (Team A), API (Team A), Logic (Team A), Database (Team A). Boundaries of services : we look at the business capabilities. Motivation behind this was quick development and we defined boundaries.

Products Not Projects

With traditional projects, the goal is to deliver a working code. No lasting relationship with customers. Often no acquaintance with customers. After delivery the team moves on to new project. With microservices, the goal is to deliver a product. Product needs ongoing support and requires close relationship with the customer. The team is responsible for the microservices after the delivery too.

You build it You run it!!

Motivation: Increase customer satisfaction. Change developers mindset.

Smart Endpoints Dumb Pipes

Traditional SOA projects have two complicated mechanism. ESB & WS-* protocols. Made inter service communication complicated and difficult to maintain. Microservices system uses dumb pipes — simple protocols. Strive to use the web already offers. Usually REST API is the simplest.

Direct connections between the service is not a good idea. Better use discovery service as a gateway. In recent years more protocols were introduced (GraphQL, gRPC)

Motivation: Accelerate development. Make the app easier to maintain.

Decentralized Governance

In traditional projects there is a standard for almost everything, Which dev platform to use, which database to use, how logs are created and, etc. With microservices each team makes it own decisions. Each team is fully responsible for it’s services and so will make the optimal decisions. Enabled by the loosely coupled nature of microservices.

Motivation: Enable making the optimal technological decision for the specific service.

Decentralized Data Management

Traditional systems have single data base. Stores all the systems data for all the components. With microservice each service has its own database. This is the most controversial attribute of the microservice. Not always possible. Raise problems such as distributed transactions, data duplication and more.

Motivation: Right tool for the right task, having the right database is important. Encourages isolation.

Infrastructure Automation

The SOA paradigm suffered from lack of tooling. Tooling greatly helps in deployment using Automated Testing & Automated deployment. For microservices automation is essential, short deployment cycles are must. Can’t be done manually. Tools like Jenkins, Azure devOps. Motivation: Short deployment cycles.

Design for Failure

With microservices there are a lot of processes and lot of network traffic. A lot can go wrong. The code must assume failure can happen and handle it gracefully. Extensive logging and monitoring should be in place. Motivation: Increased system reliability.

Evolutionary Design

The move to microservices should be gradual. No need to break everything apart. Start small and upgrade each part separately.

Summary

These are guidelines not mandatory instructions. Adopt what works for you. The microservices world is rapidly changing. Follow new API’s, monitoring and cloud services.

Notes: Componentization is important. Should be organized around business capabilities. Decentralized Governance and data management (when possible). The other important thing is Infrastructure Automation