Working with a hands-on AI application architecture

In the previous section, we recommended an architecture design for modern AI applications. In this section, we will define the specific technologies and tech stacks we will use in this book to implement the recommended architecture design. We evaluated several factors when deciding on the best choices for this book, including simplicity, learning curve, industry trends, and others. Keep in mind that there can be many valid technology choices and implementations for the recommended architecture design.

For the hands-on AI application development projects, we will use the following architecture and technology stack:

As the preceding diagram illustrates, the AI application projects will be made up of the four basic architectural components we discussed earlier:

  • User interfaces: We will be using web pages as user interfaces. We will develop relatively simple user interfaces using HTML, CSS, and JavaScript. HTML and CSS will display the UI components and handle user inputs. JavaScript will communicate with the server backend via the public APIs in the orchestration layer. The project web pages will be deployed on AWS S3 as a static website without the need for traditional web servers. This is known as serverless because we don't need to manage and maintain any server infrastructure.
We are using plain HTML and JavaScript to limit the scope of this book. You should consider single-page web application frameworks such as Angular, React, or Vue for your web user interfaces after finishing the hands-on projects in this book.

Also, you are not limited to web applications as the only choice for AI applications. Other user interfaces and modalities, such as mobile or voice assistant devices, can sometimes provide a better user experience. We recommend that you think about how the application design should be changed in order to support these other user interfaces and modalities. These thought experiments will help you build the design muscles for AI practitioners.
  • Orchestration layer: We will be using AWS Chalice, a Python serverless microframework for AWS. Chalice allows us to quickly develop and test Python applications in its local development environment, and then easily deploy the Python applications to Amazon API Gateway and AWS Lambda as highly available and scalable serverless backends. Amazon API Gateway is a fully managed service that will host our public APIs as RESTful endpoints. The API Gateway will forward the RESTful requests that were issued to our public APIs to AWS Lambda functions where our orchestration logic will be deployed to. AWS Lambda is a serverless technology that lets us run code without provisioning or manage servers. When a Lambda function is invoked, for instance, from the API Gateway, the code is automatically triggered and run on the AWS infrastructure. You only pay for the computing resources that are consumed.
  • Private APIs: We will be packaging the private APIs as Python libraries within the Chalice framework. Chalice allows us to write code in a modular way by structuring some services as libraries in the Chalicelib directory. In our hands-on projects, the private APIs are plain old Python classes with well-defined method signatures to provide access to the service implementations. In our projects, the boundary between the public and private APIs is logical rather than physical; therefore, attention must be paid to ensure the cleanliness of the architecture layers.
We will be reusing some of the private APIs in multiple projects. Our mechanism of reuse is similar to shared libraries. In larger organizations, the private APIs are usually deployed as RESTful endpoints so that different applications can easily share them.
  • Vendor services: We will be leveraging AWS for various capabilities. For example, we need to develop these intelligent-enabled applications, including AI capabilities and more. The private APIs will access the AWS services in the cloud via the boto3 SDK. Clean design requires boto3 and AWS implementation details to be completely wrapped and hidden by the private APIs; the public APIs should not know which vendor services or custom solutions are used by the private APIs to provide these capabilities.
上一章目录下一章