Not sure how I'd break my suggestions against your questions, but some of this might help...
I like to think of these microservices as startups, where each exposes their abilities via some endpoints and ideally at least one language specific client implementation. Next, I'd identify ownerships such that there's a team/individual responsible for the stability of the latest released client artifact/version (i prefer semver.org). It's okay for a team/individual to own multiple services.
The respective owners should maintain a suite of integration tests against their clients as they are being promoted from local boxes to staging servers and finally to production environments. The promotion via CI must be blocked if these integration tests fail to pass. Finally, once a service team releases a new version, they owe it to the consumers a key piece of information: the new version's backward compatibility. So for as long as a consumer isn't upgrading to a newer client version, they should not have to worry about a new release breaking their integration. Besides that, the consumers are free to upgrade to a newer client whenever they want to.
To sum it up, the owners of the services should ALSO own its reference client impl along with the integration tests. Consumers should only focus on UI tests and should not have to worry at all about the stability of the client, except for graceful handling of a broken client/microservice.
It's interesting how you've abstracted it out and not tied to a particular language and so it seems like the target audience is people who've never coded before. Few quick suggestions:
1. The design/fonts should adapt to the audience
2. Screen is a little too busy for a newbie
3. What's the end goal or # of lessons?