Software Architecture Document for the application. Cases referred to should contain central functionality, many architectural elements or specific delicate parts of the architecture. A Use Case template is available in Appendix A. If UML Use-Case notation is used in capturing the requirements, these models can be inserted.
A microservices architecture consists of a collection of small, autonomous services. Each service is self-contained and should implement a single business capability.
In some ways, microservices are the natural evolution of service oriented architectures (SOA), but there are differences between microservices and SOA. Here are some defining characteristics of a microservice:
In a microservices architecture, services are small, independent, and loosely coupled.
Each service is a separate codebase, which can be managed by a small development team.
Services can be deployed independently. A team can update an existing service without rebuilding and redeploying the entire application.
Services are responsible for persisting their own data or external state. This differs from the traditional model, where a separate data layer handles data persistence.
Services communicate with each other by using well-defined APIs. Internal implementation details of each service are hidden from other services.
Services don't need to share the same technology stack, libraries, or frameworks.
Besides for the services themselves, some other components appear in a typical microservices architecture:
Management. The management component is responsible for placing services on nodes, identifying failures, rebalancing services across nodes, and so forth.
Service Discovery. Maintains a list of services and which nodes they are located on. Enables service lookup to find the endpoint for a service.
API Gateway. The API gateway is the entry point for clients. Clients don't call services directly. Instead, they call the API gateway, which forwards the call to the appropriate services on the back end. The API gateway might aggregate the responses from several services and return the aggregated response.
The advantages of using an API gateway include:
It decouples clients from services. Services can be versioned or refactored without needing to update all of the clients.
Services can use messaging protocols that are not web friendly, such as AMQP.
The API Gateway can perform other cross-cutting functions such as authentication, logging, SSL termination, and load balancing.
When to use this architecture
Consider this architecture style for:
Large applications that require a high release velocity.
Complex applications that need to be highly scalable.
Applications with rich domains or many subdomains.
An organization that consists of small development teams.
Benefits
Independent deployments. You can update a service without redeploying the entire application, and roll back or roll forward an update if something goes wrong. Bug fixes and feature releases are more manageable and less risky.
Independent development. A single development team can build, test, and deploy a service. The result is continuous innovation and a faster release cadence.
Small, focused teams. Teams can focus on one service. The smaller scope of each service makes the code base easier to understand, and it's easier for new team members to ramp up.
Fault isolation. If a service goes down, it won't take out the entire application. However, that doesn't mean you get resiliency for free. You still need to follow resiliency best practices and design patterns. See Designing reliable Azure applications.
Mixed technology stacks. Teams can pick the technology that best fits their service.
Granular scaling. Services can be scaled independently. At the same time, the higher density of services per VM means that VM resources are fully utilized. Using placement constraints, a services can be matched to a VM profile (high CPU, high memory, and so on).
Challenges
Complexity. A microservices application has more moving parts than the equivalent monolithic application. Each service is simpler, but the entire system as a whole is more complex.
Development and test. Developing against service dependencies requires a different approach. Existing tools are not necessarily designed to work with service dependencies. Refactoring across service boundaries can be difficult. It is also challenging to test service dependencies, especially when the application is evolving quickly.
Lack of governance. The decentralized approach to building microservices has advantages, but it can also lead to problems. You may end up with so many different languages and frameworks that the application becomes hard to maintain. It may be useful to put some project-wide standards in place, without overly restricting teams' flexibility. This especially applies to cross-cutting functionality such as logging.
Network congestion and latency. The use of many small, granular services can result in more interservice communication. Also, if the chain of service dependencies gets too long (service A calls B, which calls C...), the additional latency can become a problem. You will need to design APIs carefully. Avoid overly chatty APIs, think about serialization formats, and look for places to use asynchronous communication patterns.
Data integrity. Each microservice is responsible for its own data persistence. As a result, data consistency can be a challenge. Embrace eventual consistency where possible.
Management. To be successful with microservices requires a mature DevOps culture. Correlated logging across services can be challenging. Typically, logging must correlate multiple service calls for a single user operation.
Versioning. Updates to a service must not break services that depend on it. Multiple services could be updated at any given time, so without careful design, you might have problems with backward or forward compatibility.
Skillset. Microservices are highly distributed systems. Carefully evaluate whether the team has the skills and experience to be successful.
Best practices
Model services around the business domain.
Decentralize everything. Individual teams are responsible for designing and building services. Avoid sharing code or data schemas.
Data storage should be private to the service that owns the data. Use the best storage for each service and data type.
Services communicate through well-designed APIs. Avoid leaking implementation details. APIs should model the domain, not the internal implementation of the service.
Avoid coupling between services. Causes of coupling include shared database schemas and rigid communication protocols.
Offload cross-cutting concerns, such as authentication and SSL termination, to the gateway.
Keep domain knowledge out of the gateway. The gateway should handle and route client requests without any knowledge of the business rules or domain logic. Otherwise, the gateway becomes a dependency and can cause coupling between services.
Services should have loose coupling and high functional cohesion. Functions that are likely to change together should be packaged and deployed together. If they reside in separate services, those services end up being tightly coupled, because a change in one service will require updating the other service. Overly chatty communication between two services may be a symptom of tight coupling and low cohesion.
Isolate failures. Use resiliency strategies to prevent failures within a service from cascading. See Resiliency patterns and Designing reliable applications.
Next steps
For detailed guidance about building a microservices architecture on Azure, see Designing, building, and operating microservices on Azure.
Active3 years, 10 months ago
I'm trying to come up with a checklist or set of questions/criteria to assess and evaluate proposed or emergent architectures (perform architectural reviews). What are the most important questions you ask when trying to plan, assess or review an architecture?
I know this is a large topic so I'd like to constrain it to a single end-to-end system and not the architecture for an entire organization.
Code Complete provides a decent starting point:
Architecture
Is the overall organization of the program clear, including a good architectural overview and justification?
Are modules well defined, including their functionality and their interfaces to other modules?
Are all the functions listed in the requirements covered sensibly, by neither too many or too few modules?
Is the architecture designed to accommodate likely changes?
Are necessary buy-vs.-build decisions included?
Does the architecture describe how reused code will be made to conform to other architectural objectives?
Are all the major data structures hidden behind access routines?
Is the database organization and content justified?
Are all key algorithms described and justified?
Are all major objects described and justified?
Is a strategy for handling user input described?
Is a strategy for handling I/O described and justified?
Are key aspects of the user interface defined?
Is the user interface modularized so that changes in it won't affect the rest of the program?
Are memory-use estimates and a strategy for memory management described and justified?
Does the architecture set space and speed budgets for each module?
Is a strategy for handling strings described, and are character-string storage estimates provided?
Is a coherent error-handling strategy provided?
Are error messages managed as a set to present a clean user interface?
Is a level of robustness specified?
Is any part over- or under-architected? Are expectations in this area set out explicitly?
Are the major system goals clearly stated?
Does the whole architecture hang together conceptually?
Is the top-level design independent of the machine and language that will be used to implement it?
Are the motivations for all major decisions provided?
Are you, as a programmer who will implement the system, comfortable with the architecture?
I'm looking for practical knowledge with examples, e.g., what were the most painful points in an architecture you've created?
Software Architecture Document Template
6 Answers
Based on my research, here are some architectural review checklists I've found that do this question a little more justice, and provide some background on what an architecture review is. (Seems to be a bit of confusion about it here.)
Each of these potential candidates include a number of different categories. The overall importance of these categories will vary somewhat depending on business needs. IMHO, that's OK. It's much less costly to ask another question when going through a checklist for a review and rule it out than it is to miss a question or category entirely because it didn't seem important enough to include on a checklist initially.
'Software architecture review guidelines' by Alexander Nowak
'Review Checklist for Architectural Design Document[s]' by Tom Verhoeff
'Checklist: Architecture and Design Review' from Microsoft patterns & practices Developer Center
'Conceptual Architecture Checklist' by Craig Borysowich
'App Arch Guide 2.0 Knowledge Base: Checklist - Architecture and Design' by J.D. Meier, Alex Homer, et al. (found via Peter Stuer's link)
'TOGAF Architecture Compliance Review Checklists' from the Open Group
'Architecture Review Process' by Ricky Ho
There also appears to be a white-paper written on this topic, although I have not read it. It attempts to answer this question over the course of about 11 pages.
Architecture reviews: practice and experience by Maranzano, Rozsypal, et al.
Additionally a colleague recommended a set of books from Springer, though I have not checked any of these out myself:
The Enterprise Engineering Series from Springer
Some other points to consider:
Are all stakeholders identified? (Examples: Customer, end users, business analysts, user interface designers, developers, testers, maintainers.) Is the architecture verified with the stakeholders?
How does the architecture address security?
Are the requirements to availability and reliability specified? How does the architecture address these? (Examples: mean time between failures, mean time to repair.)
How is disaster recovery handled?
Two good books for more ideas:
Software Systems Architecture by Nick Rozanski and Eóin Woods
Software Architecture in Practice by Len Bass, Paul Clements, and Rick Kazman
Is the architecture in line with the technology vendors' guidance and roadmap?
You want to get support from your chosen platform, not fight it.
e.g. For Microsoft centric solutions this means documenting where and why your choices deviate from the Microsoft Architecture guidance.
Is there a single person who can be responsible for the architecture with enough (1) technical knowledge of proposed architecture, (2) experience managing things, (3) standing in the company so that his decisions cannot be overridden by a management who doesn't know a thing.
Since (2) and (3) don't really depend on the architecture, I would find the person and ask him what he'd like to do.
Now assuming you're that person (and that's not obvious from your question -- that applies only if you think you'll still with being a chief architect of this thing for a while), I'd take an advice of Joel On Software blog and write a design specification, with the plans, goals, customers, explaining design choices, everything. That should clear the view.
Later thoughts
I tried to think a little as for what exact questions you might ask yourself after you've written the specification, like 'Is it easy to update your project', 'Does it allow flexibility in end goals', 'Will it make things easy to support', 'Are there any security problems' etc., but, while it's worthwhile to ask questions like these, I simply don't see any way they could be used for any 'evaluation' because other than with filtering out clear mistakes I don't think any specific question would help much to 'evaluate the architecture'. Perhaps your question would benefit from rephrasing?
Not the answer you're looking for? Browse other questions tagged architecturereview or ask your own question.