Midjourney’s AI’s imagination of “Shiva”

Operations must meet Specification — Cloud infrastructure development for a Conversational AI project

Software Engineering Code

The joint ACM/IEEE-CS Software Engineering Code was published as: Don Gotterbarn, Keith Miller, and Simon Rogerson. 1997. Software engineering code of ethics. Commun. ACM 40, 11 (November 1997), 110–118. DOI: 10.1145/265684.265699 — “https://ethics.acm.org/code-of-ethics/software-engineering-code/”

The following principles in particular are of interest to me for the scope of this article:

1. “1.03. Approve software only if they have a well-founded belief that it is safe, meets specifications, passes appropriate tests, and does not diminish quality of life, diminish privacy or harm the environment. The ultimate effect of the work should be to the public good.” — I intend to work with clients in accordance with this code of conduct while establishing an MoU stating that the first principle of SRE holds true. It says — “Operations is a software problem”. Let’s expand on that —
2. Operations comes under the umbrella discipline of “Software Engineering” and thus it must abide by the principle 1.03 in point above. The Operations must meet Specifications.

Screenshot of my notes on introduction to SRE. Most of it is direct reproduction of statements from the book — “Establishing SRE Foundations” — UKIS, Vladyslav. Establishing SRE Foundations A Step-by-Step Guide to Introducing Site Reliability Engineering in Software Delivery Organizations (Casey Sisterson’s Library). Addison-Wesley Professional, 2022.

In 2022 Feb, I was enumerating requirements for the first iteration for the Infrastructure as Code project to reliably and securely serve API for integration with mobile and web clients. Here’s the set of requirements I quickly jotted down after the first two meetings with the CTO:

List of exhaustive requirements requested in first meeting

At the start of my engagement with the project a point-n-click infrastructure was serving the HTTP Api. This Api was feeding the client, a demo mobile application built with Unity, for Android and for the iOS. The first course of action was to create a playbook to fix faults in this rudimentary infrastructure. Let’s call this infrastructure — “Bai-Orig”.

System Environment : Bai-Orig — How to fix infrastructure issues in Bai-Orig environment?

Next planned action — Build an elastic Infrastructure as Code that can host the microservices with a variety of compute, memory, storage needs with specified real-time latency requirements. The infrastructure would scale-out and scale-in based on CPU and Memory threshold configuration as part of Infrastructure-as-Code.

These set of images as attachments, captures the complete story categorically. Please feel free to read them for setting up your own infrastructure with AWS ECS, AWS EKS and AWS Lambdas with variety of storage options ranging from RDBMS, NoSQL to AWS EFS filesystems.

The images are presented in reverse chronological order: