Analogy
A reasonable analogy for service architecture is an organization such as a bank. The bank divides work into a variety of services such as customer service, IT services and human resource management services. Each service is independent and can be deployed to different offices. The clients of each service are offered a contract that states what can be expected of the service. For example, human resource management can help a team to recruit new staff with a form that the team fills out to initiate the process. The service structure of the firm breaks down the complex problem of operating a bank into small management chunks of functionality.Services
Services are units of software that perform a function. They are used to break complex problems into a series of simpler problems. Services are also designed to be separately deployable. This is a major advantage as it allows you to build highly scalable and resilient systems.Resilience
Resilience is a term for software that is reliable in real world conditions that includes various stresses and failures. Service architecture is a useful technique for building systems that continue to function when things fail. This is done by architecting services to be autonomous such that they don't depend on each other. Services can then be deployed to cloud infrastructure and scaled up and down as required. When an instance fails, services are smart enough to detect this and automatically find an instance that is working.Services vs Components
Services and components are two different ways to break work into manageable and reusable chunks. The difference is that services can be deployed on their own. Components are deployed with something else and therefore aren't autonomous. Services can be constructed from components. Likewise, components may use services.Service Oriented Architecture (SOA)
Service oriented architecture was an early term for service architecture that was adopted and marketed by many large IT vendors who used it to sell SOA platforms and middleware. This was a large information technology fad around 2005 that saw many top down implementations that involved buying a bunch of software and then redesigning existing systems to fit into a SOA paradigm. Much of this activity completely missed the point of SOA and project failures were common. Confusion rained as IT pundits either promoted or criticized SOA, often by making things as complex sounding as possible.Microservices
All the big-thinking and nonsense that surrounded SOA at the peak of its popularity did not stop skilled architects from using its core ideas in effective and lightweight ways that produced reliable, scalable, manageable and cost-effective systems and applications. This evolved into a new culture of software design known as microservices that is organized around a set of principles for service design.Example
A telecom company designs a billing system as a series of separately deployable services. Each service is viewed as a separate product that can be developed, maintained and managed by different people. Services are deployed to cloud and loosely coupled. When a service instance fails, the other services automatically switch to an instance that is still working. Although the problem of telecom billing is extremely complex, no single service in the architecture is complex such that each is relatively cheap to develop and manage. The services are essentially self organizing. Each publishes an API to the other services. Each knows what it needs from the other services and is smart enough to route around failed instances to find services that are responding. In other words, the architecture has no central controller or middleware.
| Overview: Service Architecture | ||
Type | ||
Definition | A software design approach that solves a problem with a series of autonomous services. | |
Related Concepts | ||
