EaaS: Everything-as-a-Service
By: Ryan S.
Tags: Economics, Technology, Cloud Computing, Business, Design

Traditional Service

The easiest way to begin defining what a service is, is to define what it is not. A service is not a product. A service, in the context of business and economics, is a transaction in which no physical goods are exchanged — it is intangible. The consumer does not receive anything tangible or theirs to own from the provider. This is what differentiates services from goods (i.e. products) — which are tangible items traded from producer to consumer during an exchange, where the consumer then owns the good.

Products compared to Services

Most people are familiar with goods versus services, and many businesses offer a combination of both. For example, many banks offer physical products such as credit cards, and also offer services like financial advice and planning. However, this is a very simple example, and in today’s world — the differentiation between products and services is becoming increasingly blurred. Let’s expand on the banking example by considering the following:

A tech consulting firm helps to develop a digital product — a mobile banking application for iOS — for their client in the retail arm of ACME Bank. They’re providing a service (software development) and the result is a tangible product (the app). ACME’s customers pay annual fees to the bank, but in return get both products and services. The mobile app, a digital product, can be used for services — like booking an appointment for financial advice or ordering a product — like a new credit card. The credit card is a physical product, but it is associated with the bank’s lending service.

This example is still fairly straightforward, but you can see how products and services are blended to create better experiences for both producers and consumers. And examples like this are happening everywhere — in both traditional and emerging businesses, creating a service ecosystem.

Traditionally, the “behind the scenes” work of developing and enabling products and services was performed through many different methods, sometimes in silos: Business Process Engineering, Traditional Project Management, Software Development, ITIL, Lean Six Sigma, etc.

Today, in the very customer-centric and employee-centric world, the details of what goes into creating these “experiences” — through products and services — is loosely known as service design.

Service Design

So we understand services in the traditional sense — a consumer is serviced by the provider. Services, like products, don’t come out of thin air. Like products, services too need to be designed in order to provide the most satisfaction to both the consumer and the provider (i.e. employees).

Even for product producers, service design is valuable when considering the experience of everyone involved in that value chain. It bridges the gaps between customer experience design and product design by considering everything in between.

Services often involve many moving parts, and service design uses the following monikers to describe service components: People, Processes, and Props. The 3 P’s are common terms used to describe the “building blocks” of Service Design.

Service Design, as you may infer from the name, utilizes the same concepts and methodologies from similar disciplines such as User Experience Design, Human-Computer Interaction, as well as Research, Ethnography, and Anthropology. There are methods to follow to ensure that experience is actually at the centre of the design, as opposed to just thinking about customers, or revenue, or brand image, for example.

High-Level Approach for Service Design

The service design framework is an iterative process and is co-created with the individuals involved in the service delivery including customers. Each phase has inputs and outputs, for example, personas, journey maps, and service blueprints.

To expand on the components of a service, let’s take a look at the high-level customer journey below — using a theoretical service for food ordering and pick-up.

Very High-Level Journey: Food Order & Pick-up Service

What are the building blocks (People, Processes, and Props) that make up the composition of this particular service? We know that it involves some technology, some people, and a physical place — but let’s dig a bit deeper.

Building Blocks that enable the Journey above

At a high-level, we can map the necessary components for each phase of the journey. Similar to the paradigm of software, services have front-end and back-end components. People, processes, and props that the customer sees, and ones they don’t. This is a very high-level view, and a service blueprint would normally contain many details of the front-end and back-end people, processes, and props involved various versions of journeys.

Also, keeping in mind our “stacked dimension” model for describing the abstraction level of services — we can see that People, Props and Processes can loosely translate to things that occur in the Business, Application, and Technology/Physical layers: Business Actors like Employees, Digital Applications, Physical Structures, Hardware, Business Processes, etc.

And that’s Service Design in a nutshell.

Service Oriented Architecture (SOA)

Around the turn of the millennium, a new systems design concept began to rise in popularity. “Service Oriented Architecture” became the craze in many organizations. Service orientation as an approach to architecture builds on similar paradigms as traditional services described above.

Similar to how a large business would offer many traditional services, a large software system often has many different functions or purposes. Traditionally, before the emergence of SOA, large-scale systems were monolithic; built on a singular codebase, with shared components, and shared infrastructure, all tightly coupled.

Service Orientation, on the other hand, is the concept of breaking up the app into components as “services”, each representing a specific business functionality. They are loosely coupled and working together to form the overall functionality of a large system.

Picture monoliths as a large, 3-tier client-server systems: a presentation layer or client such as a graphical user interface, an application layer with lots of logic in the form of methods or functions, and a data access layer connecting the system to the underlying databases.

High-Level Comparison of Architectural Styles

To add more detail, “services” in an SOA model are discrete, self-contained functions, that communicate with other components over a common protocol. Integration of services with each other, with data stores, etc. is facilitated through service brokers or service buses. A presentation layer like a GUI can consume the service through this layer.

Services — because of this — are accessible remotely and can be independently updated and maintained. For example, you could swap out one service for another in a larger application, without taking down the rest of the application. Talk about not putting all of your eggs in one basket!

A primary goal of service orientation is to promote the re-use of functions, leading to efficiencies and simpler development of new applications which are modular and can consist of existing services.

Despite the popularity and rise of SOA, there is not one sole industry standard for implementing them, and instead, there are principles, patterns, and approaches to the concept developed by many organizations. A few examples of commonalities in the service-oriented architecture approach include:

Services act as producers and consumers . The underlying logic of producer services is abstracted from the consumer — meaning they only see the endpoint.

and . The underlying logic of producer services is abstracted from the consumer — meaning they only see the endpoint. Services are both granular and composable . They are coarse-grained and represent a specific business purpose; not too granular as to reduce re-use and applicability elsewhere. Services can be combined to compose other services.

and . They are coarse-grained and represent a specific business purpose; not too granular as to reduce re-use and applicability elsewhere. Services can be combined to compose other services. Services are discoverable. They produce metadata which can be accessed over the common communication protocol and then interpreted.

If this all sounds familiar — or confusing — its because the concept of services and SOA are closely related to modern APIs, microservices, and integration standards.

Microservices

Similar to SOA, “microservices” is also an architectural style for building systems and applications that are loosely coupled. In the examples above, you’ll notice that the “functionality” in a SOA model is broken up into smaller parts. However, SOA models often share single or few underlying databases or legacy systems, and rely on a single broker layer to pass data around.

To build on this concept, microservices go a step further. They are discrete instances where the entire stack of a certain function is isolated, and various microservices are combined to compose a distributed system.

High-Level View of a Distributed System composed of Microservices

In contrast with SOA, there is no “broker” or “service bus” layer to connect various services. Instead, the microservices communicate over a lightweight protocol (such as HTTP).

Just as how service orientation provided many benefits in the early-mid 2000s, microservices also provide many benefits in the modern technology landscape.

As teams shift to more Agile and DevOps practices, microservices provide a unique advantage in the fact that various smaller teams can independently build product features for a larger application. A key principle of microservices is that they perform only one thing, and perform that thing well. With cloud platforms and containers, teams are able to quickly stand up virtual or containerized infrastructure to build their independent services. This also provides benefits for operations teams: outages in a small service do not bring down the entire system. There are even not-so-tangible benefits, for example, teams having the ability to develop services in a technology stack (language, OS, database, etc.) that they’re comfortable with — independent of the larger system.

However —as with all things — benefits come with trade-offs. With larger, heterogeneous solutions composed of many microservices with underlying components to meet each use case, comes greater complexity and different architectural concerns. For example, in traditional monolithic systems (and in some cases SOA implementations) — applications share a common database acting as a system of record. In the microservices model, each instance has its own database combining to create a system of record. This adds great flexibility for teams because a required schema change to one service’s data store doesn’t introduce changes for other teams. With that being said, you can likely imagine a scenario where services read or write data within the same domain, which can lead to challenges with data consistency and integrity.

The growth in popularity of microservices and their complexity has led to many innovations in the cloud space, including service meshes or fabrics. We will leave this more advanced topic for another time.

Software, Platforms, and Infrastructure delivered “as a Service”

Getting back to our familiar, traditional definition of service, we have seen it being applied to the procurement of information technology. Traditionally, (as in pre-2000s) software was complicated to build and manage. And as mentioned above, it still is. But, for application teams building business software, a lot of the management of underlying technologies have been abstracted. Let’s walk through the abstraction layers one more time to illustrate how this all comes together.

Abstraction model + Examples of components

Think of each of these layers consisting of various components that were traditionally sold as products themselves. You would, at the very least, need to purchase a server which would power the applications you are developing and installing. You would need storage for any persistence of data. You would need hardware for communication with the network. And on it goes up the stack — operating systems, databases, etc.

Moore’s Law and other advances in computing hardware have led way to extreme drops in the cost of computing hardware. And with cheaper hardware costs, companies are able to purchase large amounts of hardware and rent it as…you guessed it…a service.

IaaS — Infrastructure as a Service

Infrastructure as a service is a concept where providers — like Amazon, Microsoft, and Google — own large premises comprised of hardware and infrastructure. They rent virtualized access to these resources through pay-as-you-go subscription models. As mentioned earlier, this adds agility to start-ups and software teams who do not have the capital to purchase their physical resources. At the highest level, this can be compared with renting a home versus purchasing one. Using this analogy, if the start-up decides to “move” — or pivot, dissolve, sell, etc. — they can shut down their infrastructure without any long term costs or losses.

The use of IaaS generally provides the same flexibility as if it was your infrastructure. This comes with the same overhead from a managerial and operational perspective — minus managing the premises, power, security, etc.

For teams that need a more managed service, there are various “platforms” offered as a service.

PaaS — Platform as a Service

Platform-as-a-service builds on the IaaS layer, and adds abstractions which can be leveraged by development teams. PaaS hides away the complexities of dealing with operating systems, middlewares, and runtimes — and allows developers and operators to focus on writing and supporting the application, rather than infrastructure.

To go further, PaaS can be run on top of any types of hardware. For companies not yet at public-cloud maturity, the option of running PaaS on their on-premise hardware is still viable. A platform services team could manage the core PaaS infrastructure, and development teams can focus on building/deploying.

The big cloud players offer PaaS solutions on top of their IaaS — Amazon Elastic Beanstalk, Google App Engine, Azure Apps. There are also other offerings like Heroku, Cloud Foundry, and OpenShift — which will run in environments not specific to one provider.

The spectrum of responsibility: Purple = fully managed as a service.

As applications grow, the value proposition of PaaS solutions begin to wear off, considering scale often leads to unique requirements. The unique requirements in return often lead to infrastructure level challenges, which cannot be addressed through the abstraction of the application platform.

SaaS — Software as a Service

Finally, we finish off with Software-as-a-Service. SaaS refers to applications which are fully managed by the provider. This means that organizations can purchase software licenses, and immediately get to work without any development, management of infrastructure, or installation — it just works over the internet.

However, large SaaS applications are not that simple. Referencing the diagram above, you’ll notice that there is still a bit of green in the SaaS column. Often, customers will need to configure the system to meet their business requirements, add users, add some security configurations, and so on. With that said, companies can begin realizing value very quickly, often without the involvement of IT.