- Decrease your release cycle from weeks to hours.
- Scale your system without compromising your release velocity.
- Increase resilience delivering impeccable customer-experience.
When considering the move to a Microservice architecture (aka Microservices), it’s important to consider its lineage--Service Oriented Architecture (aka SOA) and the Monolithic architecture (aka Monolith).
Monolithic architecture is a software architecture encompassing the entire application business logic in a single large codebase.
Although it's considered the traditional (and sometimes the less-advised) strategy, Monolithic architecture holds many benefits and may well be the right choice for some engineering teams.
SOA, though a different style of software architecture than the Monolithic architecture, is very closely related. One can consider SOA the duplication of a Monolith across a handful of services. SOA is usually the first step when breaking away from a Monolithic architecture en-route to a Microservice architecture.
While there are differences between the two styles, it is the author's opinion that they do not merit a deep discussion. When we reference a Monolithic architecture style in this article, we also include SOA and sometimes use both interchangeably.
Microservice architecture was born from the pitfalls of the Monolithic architecture.
Microservices--also known as the Microservice architecture--is an architectural style that structures a system as a federation of a relatively high number of typically smaller services. The nature of the architecture makes individual services highly maintainable, testable, loosely coupled and independently deployable.
Each service is organized around a well defined business logic. Often located on different machines, they communicate via either synchronous and/or asynchronous messaging, based on protocols such as REST, gRPCA modern open source high performance RPC framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services., Protobuff and the like.
The Microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications as well as independent roadmaps and deployment schedules.
Conway’s law1 usually works well in organizations that practice Microservices, when teams are mapped to services.
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”— Melvin E. Conway
An organization that espouses the concepts of extreme ownership and communication will succeed with the microservice architecture, as each individual remains accountable for their service.
While Monolithic architecture provides agility and simplicity in the early days of the software life cycle when the architecture is simple, it becomes a nightmare to maintain and evolve as the software matures and architecture becomes more complex and rich with features.
Microservices on the other hand, can be overkill to start with, but become beneficial once the software becomes feature rich, enabling agility and making the software easy to evolve.
There are many similarities between SOA and a Microservice architecture. While each service in SOA looks very similar to a Monolith, it also shares many of the characteristics of a service in a Microservice architecture.
It is the author's opinion that the key difference between the architecture is the number of services that impose a different set of challenges. As the invisible rule, a human can manage up to ~10 elements in their head or in a spreadsheet, but when the number grows higher than 10, manageability becomes a challenge.
When 'manageability' becomes challenging, is where Microservice orchestration tools like Kubernetes, Docker Swarm, Docker Compose, AWS ECS and others come into play. Once you can’t manage the services and have to rely on a third party software (e.g. Kubernetes), quite a few other challenges are introduced.
If you consider the overhead of 'manageability' compared to the benefits of scalability and velocity at scale, it is worth it (if in fact, you do have as many services to manage).
The are some of the more important architectural properties that may influence an architecture choice:
Summary / Conclusion
There really aren’t as many architecture choices as it may seem. Microservices are overkill and can even inhibit velocity in the early stages. This is especially true for new teams and projects with no pre-existing infrastructure. It's better to go with a Monolith to get to the first prototype.
However, engineering teams can save themselves trouble down the road by starting with a microservice-ready monolith. Early on, you’ll start chopping off pieces to parallel services (essentially the SOA route), quickly moving to a Microservice architecture. Here, the overhead becomes smaller when compared with the benefit you earn when the software matures.
UP9 provides an out-of-the-box test automation for microservices, kubernetes and cloud-native systems, replacing the need for developers to constantly build and maintain tests, while providing comprehensive service test-coverage.
- Automatic generation and maintenance of CI-ready test-code, based on service traffic.
- Observability into API-contracts, business-logic and service architecture.
- Automatic reliability, test-coverage and root-cause analysis.
- Machine generated tests include functional, regression, performance and edge-case test-cases, covering all services and all service-endpoints.
UP9 offloads the microservice testing workload from developers, giving them precious time back.