Software development is a sophisticated process that comes with complexity built in. Enter DevOps (many years ago, of course) to foster an environment where developers can build complex applications while minimizing backend overhead, ensuring that processes are replicable and software design is standardized. One of the first examples of DevOps in action was the surge in popularity for service-oriented architecture.
Back in 2006, before the word DevOps was coined, companies such as IBM, eBay and even Harley Davidson were sharing the benefits of this architectural style. Since then, it has played a significant role in shaping modern DevOps approaches, and can act as a framework for building independent services in an integrated engineering team.
This blog will lay out what a service oriented architecture is and how it works in practice, as well as defining some key components and the tools and technologies used to make it work in practice. It will also offer comparisons with microservices architectures and monoliths, as well as sharing tips on how to implement this architectural style effectively.
What is service-oriented architecture (SOA)?
Service-oriented architecture (SOA) is an architectural style that manages dependencies between systems using discrete services instead of monolithic design. Gartner defines it as “a design paradigm and discipline that helps IT meet business demands” while Amazon calls it a “method of software development that uses software components called services to create business applications”.
SOA is a software development model built on modular systems that are self-contained and reusable. At its core, SOA gives services in your organization the ability to talk to each other. This messaging should be as simple as possible, it should require minimal development effort, and it should be independent of the technology used to build the service itself.
This modular approach requires loose coupling to work, allowing services to be easily swapped or updated without affecting the entire system. The services in SOA are self-contained pieces of code that can be written in different programming languages and can be deployed independently.
It’s best to see SOA as a counter to monolithic architectures. Where monolithic architectures present a single, indivisible unit, SOA divides functionality into distinct units, each capable of carrying out independent operations. SOA encourages systems to communicate and integrate while maintaining their independence. This approach provides more flexibility and agility in development and deployment.
How does SOA work?
At the heart of SOA is the concept that each service functions and operates independently of other services. This independence allows you to develop, deploy, and scale each service individually, making your systems more flexible and efficient.
Consider a service that provides data about the weather. here a service consumer, such as a web application or mobile app, requests weather information from our weather service. This request includes input data — perhaps the geographical coordinates of a location.
The weather service, acting as the service provider, receives this request and processes the input data. It may query a database or an API, perform some calculations, or carry out any number of tasks to generate the required weather data.
Once done the weather service sends back a response to the service consumer. This will then form the basis of its use case, such as displaying weather on a map in close to real time.
This might seem like a simple process, but it's a powerful one. By allowing services to function independently, you can develop, test, and deploy them separately. If your weather service crashes or needs to be updated, it won't affect the rest of your system. If we suddenly need to handle a surge in weather data requests, we can scale up our weather service without having to scale up every other service in our system.
We will come back to definitions of services, service consumers and service providers in more detail below.
Key components of SOA
SOA is not just about ensuring individual services work independently. It is about how these services work together as building blocks to create a modular and interoperable system. In this way, SOA is an architectural style with several key components that provide the foundation for designing, developing and implementing services. Let’s consider these components, using an ecommerce platform as an example.
If we imagine an online store, we know that its use case is to facilitate and enable sales. This requires a lot of the same assets and processes as an offline store to be taken care of. It includes presenting a store front, offering a checkout and payment processing, security and compliance measures, and much more.
In digital setting built to SOA principles, these functions are made up of individual services that are designed to operate independently, yet ultimately can only be effective by interacting smoothly with one another.
The main components in SOA terms are:
Services: every independent function that is required in the running of a store. This could include user authentication, product catalog management, shopping cart management, payment processing, and order tracking.
Service consumers: This is the entity that uses a service. For example, when a customer browses the product catalog on our e-commerce platform, the customer's browser acts as a service consumer.
Service providers: This is the entity that creates, maintains and provides the service. In our example, the store owner that manages and delivers the product catalog data is the service provider.
As well as these three components there is the service contract (interface between the service consumer and service provider), service registry (searchable directory where service providers publish service contracts), service repository (store of information about each service including its code and dependencies) and service bus (communication protocol that allows services to interact with one another).
There is also middleware, a kind of “software glue” for soa services. We will cover this in more detail in the “tools and technologies” section below.
Benefits of adopting service-oriented architecture
In broad terms, adopting SOA creates a system and culture that enables flexibility, agility and interoperability in software development. The outcomes that this can drive include:
Cost Efficiency: SOA can significantly reduce development and operational costs by allowing the reuse of existing services. This eliminates the need for redundant code and promotes efficient use of resources.
Improved Collaboration: With SOA, different teams can work on separate services concurrently, reducing the need for centralized processes and fostering better collaboration. It also allows for seamless integration between disparate systems, facilitating cross-functional team cooperation.
Business Process Optimization: By breaking down complex processes into manageable services, SOA simplifies the development lifecycle and allows for more efficient process management. A more modular approach is a more manageable approach, which allows for process optimization.
Enhanced Security: Each service in SOA can have its own security policies, providing granular control over access and ensuring that sensitive data is properly protected. This decentralized approach increases accountability, which leads to better security outcomes.
These benefits may sound familiar to those who work with microservices, and it is worth unpacking the similarities and differences between these architectures.
What’s the relationship between SOA and microservices?
Like SOA, a microservices architecture is an architectural style where applications are structured as a collection of services that are independently deployable and loosely coupled. With microservices, the communication protocol is typically Representational State Transfer (REST) or Java Messaging Service (JMS), with connectivity handled through an API rather than enterprise-wide.
Microservices are often deployed and managed in container environments, such as the open source Kubernetes. The independence of microservices makes them more fault-tolerant than alternative software architectures.
If you are evaluating soa vs microservices and you come to the conclusion that they have a lot in common, you would be right. Both rely on cloud computing or hybrid cloud and emphasize automation, granularity and agile application development. Microservices is an evolution that sits within the SOA superset, and both are a significant improvement on monolithic architecture.
That said, there are important differences, with microservices more fine-grained and SOA optimized for a broader scope of operations. These are laid out in greater detail here, and include:
Tools and technologies to support service-oriented architecture
An SOA requires several tools, or “middleware”, to align and manage services. Below are some of these tools and the pros and cons that they can offer.
Enterprise Service Bus (ESB)
Definition: An Enterprise Service Bus (ESB) is a mechanism used to facilitate communication between mutually interacting software applications within a service-oriented architecture.
Pros: An ESB offers flexible, robust message processing through a common platform.
Cons: These tools can be complex to set up and manage, as well as creating a potential single point of failure that can lead to performance bottlenecks.
Service orchestration and choreography
Definition: This refers to how services interact, either through the exchange of messaging in the domain layer of enterprise applications (orchestration) or in a decentralized manner where business logic and messaging sequence are distributed among services.
Pros: Both orchestration and choreography facilitate complex service interactions and workflows. Orchestration allows for centralized control, while choreography promotes loose coupling and scalability.
Cons: The downside of orchestration is that it can lead to tight coupling and create a single point of failure. On the other hand, choreography can become complex and difficult to manage as the number of services increases.
API Gateways
Definition: API gateways are API management tools that act as an interface, allowing clients to access backend microservices.
Pros: These simplify communication by providing a single entry point for clients, and can handle cross-cutting concerns such as security.
Cons: Like ESBs, API gateways can introduce a single point of failure or development bottleneck, and so must be carefully managed.
Integration Platform as a Service (iPaaS)
Definition: Integration Platform as a Service (iPaaS) refers to a suite of cloud services that enable development, execution, and governance of integration flows connecting processes, services, applications, and data.
Pros: iPaaS provides a scalable and flexible platform to integrate systems and services, as well as reducing the need for on-premises middleware.
Cons: It can be complex to set up and manage, as well as being incompatible with some legacy systems that don’t support web standards.
Internal Developer Portals
Definition: An Internal Developer Portal (IDP) is the engineering system of record for building high-quality software systems. These abstract away the complexities and cognitive load required to ensure software security, readiness, maturity and more.
Pros: IDPs can dramatically increase developer productivity and experience, as well as improving standards and accountability. They help with everything from debugging to routing data from web services.
Cons: Like any other wide-ranging product, using an IDP means dedicating sufficient resources to it and ensuring buy-in from developers.
How can Cortex help?
SOAs are only as good as your ability to ensure consistency in how they're developed across teams and tools. Cortex's Internal Developer Portal enables you to create templates for healthy services, and continually enforce standards of security, compliance, production readiness, and operational efficiency once they're deployed.
For example, if you want all your new services (often Docker containers) to have the same basic configuration from—at the very least—a security standpoint, and the same basic packages/libraries used across the org, Cortex's Scaffolder and Actions can enable you to build templates with boilerplate code to ensure alignment to those standards before deploying. Once the service is live, you'll need a way to see if it meets all the standards for that service (on call, SLOs, runbook etc), which Cortex Scorecards enable you to track. Finally, you'll want away to nudge engineers to fix things that fall out of alignment, with Cortex Initiatives and targeted alerting. Beyond building and monitoring new services, Cortex's catalogs enable developers to quickly reference who built what, what it does, and what it's made of.
Interested in learning more? Book a demo today to learn more about how Cortex can help you improve your Developer Experience!
