Understanding the architecture of modern AI applications

Defining a clean architecture design is a necessary step for developing successful AI applications, and we recommend four basic components that make it up.

These four components are as follows:

• User interfaces: These are the user-facing components that deliver the business capabilities of your application to the end users:
  • They are also known as frontends. Examples of user interfaces include websites, mobile apps, wearables, and voice assistant interfaces.
  • The same application can deliver different tailored user experiences by choosing different device form factors, interaction modalities, and user interfaces.
  • How you deliver intelligent capabilities on a web page is going to be very different than how you would do so on wearable devices.

As an AI practitioner, an important skill is designing the user experience to deliver your intelligent capabilities to the users. Getting this part right is one of the most important factors for the success of your AI applications.

• Orchestration layer: These are the public APIs that will be called by your user interfaces to deliver the business capabilities:
  • Usually, these APIs are the entry points to the backend.
  • The public APIs should be tailored to the specific interfaces and modalities in order to deliver the best experiences to the users.
  • The public APIs will call upon one or more small services (through private APIs) to deliver business capabilities.

They play an orchestration role to combine several lower-level capabilities to compose higher-level capabilities that are needed by the user interfaces. There are other names for these public APIs that you might be familiar with; that is, Backends for Frontends (or BFFs) and experience APIs.

• Private APIs: The private APIs define the interaction contracts that are used by the public APIs to access lower-level services:
  • The private APIs wrap the service implementations, which provide certain capabilities, in order to hide their details.
  • These APIs play a key role in the composability and the replaceability qualities of software systems.
  • The private APIs are the interfaces for the common capabilities that can be composed and reused by multiple applications.
  • These private APIs follow the service-oriented design pattern. You might be familiar with this pattern from similar architectures, such as microservices architecture and service-oriented architecture (or SOA).
  • They should be designed with the single responsibility principle in mind.

A set of well-designed private APIs is a valuable asset and competitive advantage for any organization. The organization will be able to rapidly innovate, improve, and deploy solutions to the market.

• Vendor/custom services: These are the implementations of the business capabilities, whether they are AI or otherwise:
  • These implementations can be provided by vendors as web services or hosted within your infrastructure. They can also be custom solutions that have been built by your organization.
  • These services have their own APIs, such as RESTful endpoints or SDKs that the private APIs will call upon to wrap the implementations.

In this book, we will be leveraging Amazon as the vendor to provide many of the web services via the boto3 SDK. Later in this book, we will also teach you how to build custom AI capabilities using AWS' Machine Learning services and deploy them as ML models with RESTful endpoints.

The following diagram illustrates the organization of these basic architecture components and layers:

The key to a clean architecture is to keep these components separated through well-defined interaction contracts between each layer:

• The user interfaces should only know about the public APIs in the orchestration layer.
• The public APIs should only know about the private APIs that they depend on.
• The private APIs should only know about the service implementations they wrap around.
• This is the principle of information hiding, which is applied at the architecture level.

There are many benefits to enforcing these logical boundaries at the architecture level, for example, if we would like to switch to a better vendor service. All we need to do is create a new set of private APIs to wrap around the new vendor service while keeping the same private API contracts to the public APIs (and then retire the old private APIs). This way, the public APIs, as well as the user interfaces, won't be affected by this change. This limits the impact of the change to a specific part of the application.