- 4.1 Do DevOps Practices Require Architectural Change?
- 4.2 Overall Architecture Structure
- 4.3 Quality Discussion of Microservice Architecture
- 4.4 Amazon's Rules for Teams
- 4.5 Microservice Adoption for Existing Systems
- 4.6 Summary
- 4.7 For Further Reading
This chapter is from the book
This chapter is from the book
This chapter is from the book
4.5 Microservice Adoption for Existing Systems
Although microservices reflect the small, independent team philosophy of DevOps, most organizations have large mission-critical systems that are not architected that way. These organizations need to decide whether to migrate their architectures to microservice architectures, and which ones to migrate. We discuss this migration somewhat in Chapter 10. Some of the things an architect thinking of adopting a microservice architecture should ensure are the following:
- Operational concerns are considered during requirements specification.
- The overarching structure of the system being developed should be a collection of small, independent services.
- Each service should be distrustful of both clients and other required services.
- Team roles have been defined and are understood.
- Services are required to be registered with a local registry/load balancer.
- Services must renew their registration periodically.
- Services must provide SLAs for their clients.
- Services should aim to be stateless and be treated as transient.
- If a service has to maintain state, it should be maintained in external persistent storage.
- Services have alternatives in case a service they depend on fails.
- Services have defensive checks to intercept erroneous input from clients and output from other services.
- Uses of external services, environmental information, and third-party software and libraries are localized (i.e., they require passage through a module specific to that external service, environment information, or external software or library).
However, adopting a microservice architecture will introduce new challenges. When an application is composed of a large number of network-connected microservices, there can be latency and other performance issues. Authentication and authorization between services need to be carefully designed so that they do not add intolerable overhead. Monitoring, debugging, and distributed tracing tools may need to be modified to suit microservices. As mentioned earlier, end-to-end testing will be expensive. Rarely can you rebuild your application from scratch without legacy components or existing data.
Migrating from your current architecture to a microservice architecture incrementally without data loss and interruption is a challenge. You may need to build interim solutions during this migration. We discuss these challenges and some solutions in the Atlassian case study in Chapter 13, wherein Atlassian describes the initial steps of their journey to a microservice architecture. An architect should have a checklist of things to consider when performing a migration.