STN-3000.02: Container Hosting

STANDARD SUMMARY

Intended Audience: IT personnel, Procurement personnel, Faculty supporting student projects
Standard Owner: Associate Director of Enterprise Infrastructure Services (EIS)

A container is an isolated, lightweight method of making an application or service available without requiring a full server. Information Technology Services (ITS) provides both cloud and on-premises options for hosting containers. ITS hosts three categories of containers: 

1. Internal IT utilities. 
2. Enterprise services and applications. 
3. Student projects. 

Containers must conform to the principles of microservice architecture; exceptions must be approved by the Associate Director of Enterprise Infrastructure Services/Principal IT Architect. 

Container owners are responsible for maintaining the security and functionality of their container images. Student projects must have a faculty or IT staff sponsor and a defined termination date. 

For the complete standard, click "Full Document" tab at top of page.

FULL DOCUMENT

Intended Audience: IT personnel, Procurement personnel, Faculty supporting student projects
Standard Owner: Associate Director of Enterprise Infrastructure Services (EIS)

1. Definitions

2. Container Hosting Options

Information Technology Services (ITS) supplies container hosting and orchestration, in both our Azure cloud infrastructure and our on-premises virtualization environment. ITS hosts three categories of containers:

1. Internal IT utilities.
2. Enterprise services and applications.
3. Student projects.

3. Container Hosting Requirements

3.1 Patching and Maintenance Requirements

All containers in the on-premises virtualization environment are subject to standard patching and maintenance windows for the underlying host systems. Container application owners are responsible for ensuring continuity of service through container replicas or other means.

Container application owners are responsible for maintaining their container images, including patch-level updates.

3.2 Requirements for Internal IT Utilities, and Enterprise Services and Applications

Containers are not a substitute for virtual machines. Containers are an alternative to virtual machines, suitable for a subset of use cases. In general, an application or service should run in a container when it meets the following requirements:

• Stateless: Applications and services running in containers should be stateless in design, and not rely on session history or affinity to effectively perform their intended functions.
• Dynamic: The application or service should not rely on a static resource, such as a static IP address or persistent file storage, to effectively perform its function. Any persistent data generated by the application or service should be stored in and retrieved from a decoupled data store, such as a database on a separate server.
• Lightweight: An application or service running in a container should be designed from the principles of microservice architecture: a decoupled, cohesive application developed as a suite of small services, each running in its own process and communicating with lightweight mechanisms [such as a Hypertext Transfer Protocol (HTTP) resource API], independently deployable by a fully automated mechanism.

An application or service that does not meet the above requirements may be better suited for deployment on a virtual machine or cloud service.

3.3 Additional Requirement for Enterprise Services and Applications

Any user-facing enterprise applications or services deployed to the ITS virtualization environment in a container must first undergo an architectural review by the Associate Director of Enterprise Infrastructure Services/Principal IT Architect or designee.

3.4 Additional Requirements for Student Projects

• Student projects must have a designated sponsor who is either a faculty member, or a staff member with an IT role.
• Student projects must have a termination date by which ITS may remove the project from the virtualization environment.
• Student projects may not access secured networks or sensitive data without permission from the relevant system owners and data custodians.
• ITS personnel will remove any containers from the virtualization environment that they consider a risk to the security or operation of any IT systems.

4. Exceptions

The Principal IT Architect may approve any exceptions to the requirements documented in this standard.

5. Authority

1. University policy POL-U3000.04: Computer Use  – Responsible Computing

6. References

1. “Characteristics of a Microservices Architecture” by Martin Fowler

https://martinfowler.com/articles/microservices.html

2. "Microservices Architecture on Azure Kubernetes Services”

https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/containers/aks-microservices/aks-microservices

Change Log