7. Deploy a New Service

7.1. Intro

This page is a work-in-progress aimed at capturing all of the details needed to deploy a new service in the edX environment.

7.2. Considerations

7.2.1. What Does Your Service Do

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

7.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?

7.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?

7.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?

7.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?

7.2.6. License

Is the license included in the repo?

7.2.7. How does your service run

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

7.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.

7.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.

7.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.

7.2.11. Messaging

Does your service need to access a message queue?

7.2.12. Email

Does your service need to send email?

7.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.

7.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.

7.2.15. Fault Tolerance and Scalability

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

7.2.16. Network Access

From where should your service be accessible?

7.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

7.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.

7.2.19. Additional Requirements

Anything else we should know about.