Microservice Architecture

Description

OVERVIEW OF MICROSERVICE ARCHITECTURE

Today, thousand of microservice are replacing hundreds of enterprise app within an organization—driving exponential growth 
in the number of programmable endpoint handled by APIs.Microservices are one of the most important and popular software architecture trends. This architecture forms the base for a lot of companies including: Amazon, Netflix, Spotify, and Uber.if you are developing a large/complex application
and you need to deliver it rapidly, frequently and reliably over a long periods of time
then the Microservice Architecture is often a good choice.

Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services

CLOUD-NATIVE; IDEAL FOR NETWORK-DISTRIBUTED INTEGRATIONS:

Lightweight stateless container with low memory footprint, fast bootup time, and built-in capabilitie for automated CI/CD workflows.

DEVELOPER-FIRST AND OPS FRIENDLY:

Uses the OpenAPI Specification (OAS), which means developers can collaborate in creating APIs and then test them independently.

SUPPORT FOR TRANSFORMING LEGACY API FORMATS:

The microgateway can transform API request and response from legacy formats to modern ones, so they can be exposed to modern consumer apps.

SUPPORT FOR COMPOSING MULTIPLE MICROSERVICES:

Enables developers to expose a combination of microservice via a single API in line with modern best practices.

RUN-TIME SERVICE DISCOVERY:

Automatically discovers microservices, which often see IP address changes as a result of being redeployed.

ENHANCED SCALABILITY:

The microgateway can run in isolation with no dependencies on other components, which enables greater scalability and smoother upgrades.

We propose the following set of core principles for microservice design:

Interface Segregation

Deployability

Event-Driven

Availability Over Consistency

Loose Coupling

Single Responsibility

Reliability:

We live in a cloud computing and microservices world. It’s no longer sufficient to simply check that a single server is running and our application process is still alive. We need to implement more advanced techniques like circuit breakers and health checks.

Circuit Breakers:

One microservices pattern for reliability is circuit breakers, which analyze the live traffic to a service to verify if the service responds to requests appropriately.

Health Checks:

Health checks are exactly what they sound like. We need to verify that service instances are ready to handle requests.

Service Discovery:

The final piece in ensuring reliability involves service discovery within our service mesh.

Monitoring:

Now that our services are resilient to some failures, we need to monitor those services. As mentioned earlier, monitoring microservices is much more complicated than monolithic applications.In a monolithic application, all of our logs are in one place. We can inspect the logs from a single dashboard and use a single id to troubleshoot an issue. In the microservice world, we need to track a single request across multiple services. For this, we need distributed tracing.

Security Patterns for Microservice Architectures

Third-party dependencies make up 80% of the code you deploy to production. Many of the libraries we use to develop software depend on other libraries. Transitive dependencies lead to a (sometimes) large chain of dependencies, some of which might have security vulnerabilities.You can use a scanning program on your source code repository to identify vulnerable dependencies. You should scan for vulnerabilities in your deployment pipeline, in your primary line of code, in released versions of code, and in new code contributions.

You should use HTTPS everywhere, even for static sites. If you have an HTTP connection, change it to an HTTPS one. Make sure all aspects of your workflow.GraphQL uses HTTP, so you don’t have to do any extra logic from a security perspective. The biggest thing you’ll need to do is keep your GraphQL implementation up-to-date. GraphQL relies on making POST requests for everything. The server you use will be responsible for input sanitization.

OAuth 2.0 has provided delegated authorization since 2012. OpenID Connect added federated identity on top of OAuth 2.0 in 2014. Together, they offer a standard spec you can write code against and have confidence that it will work across IdPs (Identity Providers).JSON Web Tokens (JWT) have become very popular in the past several years, but they’ve also come under fire. Mostly because a lot of developers try to use JWT to avoid server-side storage for sessions