Photo by David Bruno Silva on Unsplash
Service-oriented architecture (SOA) allows building distributed software systems that are the opposite of monolithic applications. SOA apps substitute a network of loosely-couplet services that interact with each other via interfaces using standard communication protocols. Such approach to structuring apps has already became a long-term trend.
Successful startups and enterprise-scale projects often adopt this architectural approach to improve performance and simplify the development of existing software. Let’s consider the reasons and benefits of such transformation.
When to use service-oriented architecture?
Although SOA and microservices are trending, it’s still a rare case for an application to have this architecture from the start. MVPs and first versions of apps are usually built as monoliths. Later, if a project gets traction, developers migrate it from the monolithic architecture to SOA.
Migrations to SOA often take place at successful startups facing exponential growth and striving to scale very fast. Sometimes, SOA is introduced by mature companies facing problems with legacy code undermining the efficiency of their software systems. Moving to a different app architecture is complex and requires significant investments. Moreover, no one would tell that SOA is 100% better than monolithic because it has its own challenges. SOA apps are more difficult to orchestrate and test.
So why do companies take risks and make such a huge transformation of their products? The tendency is that the more mature the software gets, the more reasons appear to move from the initial monolithic architecture to SOA:
- The number of features is growing and each logical part of the monolithic app begins to take on too many responsibilities.
- The dependencies between different parts of the app multiply and with every next version the code gets harder and harder to navigate.
- Companies store gigabytes of spaghetti code in their repositories and deal with a giant and complex database.
- The engineering team is growing and developers experience more issues with code integration and deployment, which becomes a common source of frustration.
- The development speed slows down, technical debt is growing, and the whole system becomes too difficult to adapt to the business needs and requirements.
All those symptoms indicate that it’s time to spit the monolith app into smaller independent services. The advantages that SOA promises are often the keys to solving the mentioned pain points.
Benefits of service-oriented architecture
How do the stakeholders win from turning their project into a lego house built of separate blocks? To understand why companies implement the service-oriented architecture, let’s look at the advantages it brings for business and for the engineering team.
SOA allows software engineers to take advantage of:
- Separation of concerns between different services. Every service inside the app executes a narrow pool of tasks and leverages hardware infrastructure that ensures its best performance.
- Simultaneous and autonomous development. Every service is developed, deployed, and maintained by a separate team with minimum influence on the rest of the system.
- Combination of different languages and technologies. Every service can be written in the language that suits best for its purpose and communicates with the rest via a standardized communication protocol.
- Reusing code at scale. As services represent self-contained code packages they enable code reuse on a macro level, which may significantly reduce development time for new functionality.
SOA empowers businesses to:
- Quickly react to changes in the business landscape. SOA simplifies adding new or upgrading existing functionality and ensures faster time to market for every new feature.
- Make the most out of existing assets. An application as a whole has less downtime and rarely becomes affected by the updates made in its separate parts.
- Interact with customers on multiple platforms. Separate teams can develop additional services for different platforms and devices (web, mobile, or smart TV) and integrate them into the system seamlessly.
- Enable horizontal scaling where needed. Separate services can be scaled up and down to address the load they get, which helps to use infrastructure efficiently.
- Services correlate with business goals. It’s easier to define the scope and document requirements for every service as they match with particular business processes and goals.
However, before the companies get the first benefits of service-oriented architecture they have to make their way through challenging and painful transformations. This process may take years for a large project.
How is SOA implemented?
There are two common ways for companies to implement SOA in a running project. If they want to introduce a new language or technology, they opt for parallel development of new applications. If they want to reuse their legacy code at maximum, they choose to carve out pieces from the existing apps and create network-enabled wrappers around them.
Parallel development of a new app
If your company has a sufficient budget for migrating your app to SOA architecture, you can hire a separate team to rewrite your software from scratch. Your existing app will continue to function and update until the new one catches up with it by the scope of functionality. As soon as the new app is ready, you’ll swap the old one for it.
The main drawback of this approach is the risk that the alternative new app may never catch up with the old one because the latter can’t remain unchanged for a long time. The more dynamic is the business landscape the higher the risk is.
Breaking the old monolith into pieces
If you have a solid code base and don’t plan to move to a new language, you may want to split your monolith into small and loosely-coupled services gradually. In this case, your developers will have to extract pieces of code into separate packages, then turn them into self-contained services, and set up communication between them and the rest of the system.
This approach implies that your team will choose small chunks of functionality, turn them into self-contained modules, manage dependencies on external code, create wrappers around those modules, write APIs for communication with the application, swap direct requests to the old code for calls to the new modules.
After the whole app is split into modules, they’ll be further tuned to become a network of independent services that exchange requests and responses with each other using REST or SOAP protocols. At the following stages, your team will have to do a lot of optimization work on orchestration, testing, and scaling components of the new SOA application.
Need to migrate your monolithic app to SOA?
Moving from monolith to SOA is a journey to take with the best. At Proxify.io you’ll find senior developers that worked with both small and enterprise-level applications. They can help you rewrite your application in another language or extract functionality from a monolith and turn it into a network of stable and scalable services. Send us your talent request and meet a trustet software architect within two weeks.
