The growing perception in application development is that heavyweight monoliths are cumbersome and costly to the business. A monolith is an application built over a long period of time to meet growing and changing requirements of the business. After a million lines of code and hidden dependencies, the application is easily broken during development. However, the business depends on the monolith so much that replacing the application with a comparable product is nearly impossible. Therefore, a new strategy is required.
Microservices is another form of Service-Oriented Architecture (SOA). The idea with microservices is to break the application down into independently deployable services supporting a specific business goal and communicating with other services through a lightweight, well-defined interface. A microservice has a few lines of code which are managed separately from other microservices. An application can have hundreds of microservices.
The advantages to microservices are primarily in service autonomy, scalability, and robustness. When a service breaks, there is minimal impact to other services within the application and therefore, to the whole application. Changes can be made to a single microservice without affecting the application. As a result, development of microservices is performed at different speeds and priorities. Scalability is relative to the resources required for independent services, rather than the entire application; making resource management more efficient and cost-effective. Focusing on individual services enables development teams to create more robustness in functionality.
The microservice approach is ideal for systems still in their infancy. The challenge comes with moving away from established monoliths: where individual components within the application have a high degree of complexity and dependency with the rest of the application. When transitioning an established application, the microsystem approach can break the whole application as the microsystem will focus on a few lines of code.
Enter Self-Contained Systems (SCS), where the monolith is divided into functions. Like microservices, SCSs are autonomous, replaceable applications, typically web-based. However, an SCS is larger than a microservice and may even contain multiple microservices. Consider an application from an enterprise perspective. A monolith meets the strategic enterprise requirements often at the expense of tactical and operational requirements. A self-contained service breaks those enterprise requirements into functions or business processes which can be well-defined and independently managed. This can be the tactical level of the application. Microservices focus on the individual tasks required to successfully complete the process, or the individual operations of the application.
The primary difference between SCSs and microservices is communication. Each will have business logic and data management, but microservices are expected to communicate with other microservices: a task must communicate to the next task whether it is complete or not. Many microservices may share a user interface (UI). As a result, many resources are utilized to perform and manage the communication between microservices. Self-contained systems are encouraged not to communicate with other self-contained systems; though communication will occur within the system. Additionally, microservices will support integration at the logic level of the application, while SCSs encourage integration at the UI level.
For established monoliths, the SCS approach is preferred as the application is divided into different functions, such as searching, invoicing, and checkout. Each of these functions may have individual tasks developed as microservices, but they are managed as a whole with other services and systems. When transforming a monolith, SCS are a better option because individual functions are the focus, rather than individual lines of code. A single self-contained system can be developed and deployed without affecting the entire application until the monolith is completely replaced. If the monolith contained a million lines of code, these lines may not require any modification and can remain without any change. The SCS with its own user interface, business logic, and data management capabilities can be added without impacting the monolith significantly. Additionally, one team is responsible for a single SCS making development, maintenance and operation more cost-effective and efficient over time
Everything you need to know about outsourcing technology development
Access a special Introduction Package with everything you want to know about outsourcing your technology development. How should you evaluate a partner? What components of your solution that are suitable to be handed off to a partner? These answers and more below.