Micro-Frontends (MFE) are the technical representation of a business subdomain, they allow independent standalone implementations for a domain area.
Sunday 6 February 2022
Micro-Frontend Architecture Pattern
Friday 22 May 2020
Micrososervice and SOA introduction
What are Microservices: A type of SOA, basically distributed computing. Microservices are a subset of SOA but with loosely couple architecture. Independent deploy-able services, tries to reduce/remove other services dependency on a specific service. I can change a service and it does not affect other service/break existing services. Allows us to have a small scope of release, therefore easy to test and increase release frequency. Services will depend on other services. SOA is older but both are well tried and tested. Microservices is generally preferred but it's much easier to move to SOA for a monolith.
Monolith Systems: Monolith are the way most systems were built, large full deployments. All code is packaged into a large module of code. They are simple and often are sometimes fairly appropriate such as on-prem. software. Beware the Distributed Monolith: Separate services but high dependent, end up having to co-ordinate deployment between code bases.
More on SOA: Independently deploy able, DDD for scoping works well for defining Microservices. Need to get the boundaries right is key. Using Bounded Context is a good way to have multiple related models and show their overlapping points.
Each service operates in isolation which are processes. Allow us to scale independently. Containers are good for hosting these services. Communication generally done over request/Response (most commonly HTTPS) e.g. REST API or Event-Driven e.g. Azure Service Bus. Event is broadcast from the service, listening services is responsible for listening to the event.
Encapsulation of data, the data is hidden inside the Microservice boundary. Allows for independent deployment.
Main Benefits of SOA:
- "Microservice buy you options";
- As smaller independent units are deployed, which leads itself to faster deployments to production using CI and CD. More teams/devs can work independently;
- Defense in Depth Security;
- Scalability from performance - Scale up, identify bottlenecks (change tech or scale service hosting bottleneck);
- Failure Independence - tolerate partial failures, service redundancy;
- Cost - focus cost as needed, scale up and down. Deliver service quickly, can replace with better technology e.g. service use an expensive workflow software to do some logic, as business grows, build a C# service that does the work faster, better, and lower cost and no need to BPM.
Note: SOA does not guarantee these benefits, you need to adjust to get them
Tip: Still use similar technology stacks and patterns, don't allow each service to be built without considering the consumers. Try keep on a similar stack e.g. don't use C#, NodeJS, Python, Go for different web services.
Sunday 3 May 2020
Common Software Architectural Patterns
1) Presentation/UI layer
2) Business Logic
3) Data Layer/Data source
Here are a couple of possible example over the years you could of used
ASP > C++ Com > SQL Server 2000
ASP.NET (Web Forms) > C# Web Service (XML/SOAP) > SQL Server 2008
ASP.NET C# > C# Business Object Layer > SQL Server 2008
KO > MVC > SQL 2012
Angular 3 > C# Web API (swagger contract) > SQL 2016
REACT.JS > Node.JS > Amazon Redshift
UI > Azure Functions/Serverless > SQL Azure
Flutter > C# Web API .NET Core 3 (swagger/OpenAPI) published on Azure App Service > SQL Azure/Cosmos
- Proprietary formatted API's >
- XML with SOAP coming out of XML based API's >
- REST/JSON (other popular formats are: RAML, GraphQL >
- Event Driven API's may be the next big jump.
Thoughts: As time has progressed, scaling each of these layers has become easier. For instance Azure SQL has replication and high Availability and scalability automatically built in. No need to think about load balancing in depth. Plug and play and ask for more if you need it.
Microsoft SQL Server use to be a single server, then came replication, clustering, Always-on-availability, scaling greatly improved performance.
Middle Tier or Business layer use to be a singleton pattern - go thru a single server for business logic, slowly load balancing improved and caching become better. Nowadays merely ramp on on you cloud provider.
Sharded Architecture: Application is broken into many distinct units/shards. Each shard lives in total isolation from the other shards. Think SOA or Microservice architectures often use this approach. "SOA is focused on application service reusability while Microservices are more focused on decoupling".
Source: https://kkimsangheon.github.io |
- Complexity - Difficult to change code and know the effects. Also services need to be deployed together to test changes.
- Resilience - Service goes down, the whole suite goes down.
- Scalability - Can be an issue as the slowest component becomes the bottleneck.
- Developers & Teams can work independently
- Great to reuse existing services instead of creating yourself. e.g. App Insights on Azure.
- Great for high availability and targeted scalability.
- Zero trust security. Least privilege access. Defense in depth.
- Focused costs by scaling the individual microservices.
- Services need to be Independence or deployment becomes a challenge.
- Increased latency - you may need to go to various systems in sequential order.
- Need keys to manage e.g. clientId for this decouple architecture type, this architecture can also become complex especially if you need to expand a shard to do something it doesn't do today.
- Data aggregation and ETL can become complex and have time delays.
- Referential integrity, guarenteed comit is an issue, can use SAGA or 2PC to improve but not ACID.
- Need rules and strict governance and communication between teams.
- Monitoring and troubleshooting can be tough. Build a great traceable service (App insights for instance needs to be pollyfilled forlong running operations, SPA's need unique correlationIds)
- Client/Service sends a broadcast event
- Consumers listens for events to see if they want to use the event
Command Query Responsibility Segregation (CQRS) - pattern/method for querying and inserting data are different./seperated. This is a performance and scaling pattern.
Domain Driven Design (DDD) - Design software inline with business requirements. The structure and language of the code must match the business domain. DDD Diagrams help create a share understanding of the problem space/domain to aid with conversation and further understanding within the team. "Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships." Martin Fowler.
Azure Messaging Service is made of of 6 products:
1. Service Bus - Normal ESB. Messages are put into the queue and 1 or more apps can dirrectly connect or subscripbe to topics.
2. Relay Service - Useful for SOA when you have infra on prem. Exposes cloud based endpoints to your on-prem. data sources.
3. Event Grid - HTTP event routing for real time notifications.
4. Event Hub - IoT ingestion, highly scalable.
5. Storage Queues - point-to-point messaging, very cheap and simple but very little functionality.
6. Notification Hub -
Lambda: great for large data architectures. Has a batch vs streaming concept. Each transaction pushed into a queue/stream (Kafka/Azure Queues/Azure Event Grid) and large data can be stored for later batch processing.