11. Deploy a New Service¶

11.2.1. What Does Your Service Do¶

Understanding how your service works and what it does helps Ops support the service in production.

11.2.2. Sizing and Resource Profile¶

What class of machine does your service require? What resources are most likely to be bottlenecks for your service: CPU, memory, bandwidth, something else?

11.2.3. Customers¶

Who will be using your service? What is the anticipated initial usage? What factors will cause usage to grow? How many users can your service support?

11.2.4. Code¶

What repository or repositories does your service require. Will your service be deployed from a non-public repo?

Ideally your service should follow the same release management process as the LMS. This is documented in the wiki, so please ensure you understand that process in depth.

Was the service code reviewed?

11.2.5. Settings¶

How does your service read in environment specific settings? Were all hard- coded references to values that should be settings, such as database URLs and credentials, message queue endpoints, and so on, found and resolved during code review?

11.2.6. License¶

Is the license included in the repo?

11.2.7. How does your service run¶

Is it HTTP based? Does it run periodically? Both?

11.2.8. Persistence¶

Ops will need to know the following things.

• What persistence needs does you service have
  • Will it connect to an existing database?
  • Will it connect to Mongo
• What are the least permissive permissions your service needs to do its job.

11.2.9. Logging¶

It is important that your application logging in built out to provide sufficient feedback for problem determination as well as ensuring that it is operating as desired. It is also important that your service log uses our deployment standards, for example, logs vs. syslog in deployment environments, and the standard log format for syslog. Can the logs be consumed by Splunk? They should not be if they contain data discussed in the Data Security section below.

11.2.10. Metrics¶

What are the key metrics for your application? Concurrent users? Transactions per second? Ideally you should create a DataDog view that captures the key metrics for your service and provided an instant gauge of overall service health.

11.2.11. Messaging¶

Does your service need to access a message queue?

11.2.12. Email¶

Does your service need to send email?

11.2.13. Access to Other Service¶

Does your service need access to other services, either within or outside of the edX environment? Some example might be, the comment service, the LMS, YouTube, s3 buckets, and so on.

11.2.14. Service Monitoring¶

Your service should have a facility for remote monitoring that has the following characteristics.

• It should exercise all the components that your service requires to run successfully.
• It should be necessary and sufficient for ensuring your service is healthy.
• It should be secure.
• It should not open your service to DDOS attacks.

11.2.15. Fault Tolerance and Scalability¶

How can your application be deployed to ensure that it is fault tolerant and scalable?

11.2.16. Network Access¶

From where should your service be accessible?

11.2.17. Data Security¶

Will your application be storing or handling data in any of the following categories?

• Personally Identifiable Information in General, e.g., user’s email addresses.
• Tracking log data
• edX confidential data

11.2.18. Testing¶

Has your service been load tested? What there the details of the test. What determinations can we make regarding when we will need to scale if usage trend upward? How can ops exercise your service in order to tests end-to-end integration. We love no-op-able tasks.

11.2.19. Additional Requirements¶

Anything else we should know about.