From a Rails monolith to microservices on Kubernetes

Private, instructor-led training for developers who need to deploy and operate independently released services on Kubernetes after a Rails monolith.

Your team already knows how to release the current application. Separate services introduce network dependencies, independent health checks, and failures that can affect multiple releases.

LearnKube connects application development to Kubernetes operations through a small multi-service application. Your engineers will get hands-on practice with independent deployment, dependency diagnosis, and recovery.

Discuss your team's training

Hands-on learning and the skills engineers take back to work.

Preview: course-wide figures are not yet available.

  • Hands-on learning
    60%
    Of instruction time spent on labs and challenges.
  • Troubleshooting confidence
    86%
    Of respondents report greater confidence diagnosing Kubernetes problems.
  • Relevant to your work
    92%
    Of respondents say the course addressed their engineering responsibilities.
  • Skills put into practice
    95%
    Of respondents applied their new skills at work within 90 days.

Operate services with independent lifecycles

  • Deploy separate services by defining images, Deployments, and runtime configuration, so each service can release on its own schedule.
  • Preserve request handling by configuring probes and rehearsing compatible updates, so one service's release does not unnecessarily interrupt its callers.
  • Locate failed requests by inspecting service endpoints, logs, and dependency responses, so engineers identify the component that needs attention.
  • Agree on release ownership by documenting dependency expectations and recovery responsibilities, so teams can coordinate changes across service boundaries.

A service boundary becomes an operating responsibility

A Rails monolith can package many application functions into one release. With microservices, those functions cross network and deployment boundaries. Kubernetes manages replicas of each service, but the application still needs compatible interfaces and clear dependency behavior. A successful rollout of one component does not establish that every request succeeds.

I keep dependency failures out of liveness checks unless a restart can help the process recover. When a downstream service fails, unnecessary restarts of healthy callers can spread the disruption across the application.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Release the applicationIndependent Deployments and versionsUpdate one component
Call application functionsServices and network dependenciesTrace a failed request
Decide application healthPer-service readiness and livenessEvaluate probe behavior
Handle increased demandPer-service resource metricsScale a busy component

Your team is not alone in this architecture change

Flexport's Customs engineering work includes a move from a React/Flow and Ruby on Rails monolith toward React/TypeScript and Kotlin microservices on Kubernetes.

That change gives developers new deployment and operational responsibilities alongside application development. Kubernetes training addresses releases, traffic, and recovery. Service design and language conversion remain application engineering work.

For this kind of transition, we recommend a four-day workshop focused on independent releases, service discovery, and diagnosis across dependencies.

A recommended four-day workshop for application developers

This proposed agenda uses a small application with services deployed separately. We start with container and Kubernetes basics, then connect each module to your application's behavior.

Day 1

You will connect container images and configuration to Pods, Deployments, and Services. We explain readiness, liveness, rolling updates, and rollback through a release with dependent services.

Hands-on exercises

  • Deploy two application components with separate release lifecycles.
  • Introduce an unhealthy version and restore the affected service.

Day 2

We introduce Helm releases and Kustomize, then explain the controllers and nodes that run your application. You will distinguish a release change from recovery after an infrastructure failure.

Hands-on exercises

  • Package separate service versions and configuration in Helm releases.
  • Simulate a node failure and inspect application recovery.

Day 3

You will trace how DNS, Services, ingress, and network policies affect requests in your application. We discuss when to use a service mesh and how placement choices affect availability.

Hands-on exercises

  • Trace a request from ingress through two application services.
  • Diagnose a dependency failure caused by a selector or network policy.

Day 4

We show how secrets, persistent storage, and autoscaling relate to each service's needs. You will discuss database access, workload permissions, and how adding replicas differs from increasing database capacity.

Hands-on exercises

  • Configure a service's credentials and persistent data dependency.
  • Apply an uneven load and observe which component needs more replicas.

Your service boundaries, database dependencies, and release responsibilities can shape the agenda. Get in touch to tailor the workshop to your move from a Rails monolith to Kubernetes microservices.

Examine failures across service boundaries

If an engineer adds every downstream dependency to a liveness check, the instructor can show how one outage triggers unnecessary restarts. Your team can compare readiness and liveness choices with how the application handles requests.

It's a great course that helped me fill in the gaps of my Kubernetes understanding

— Asiya, Data Science, EDF Trading.

Bring your release and dependency model

Tell us how you release the Rails application, which services will run on Kubernetes, and who will own their operations. We will recommend exercises around those deployment boundaries.

Discuss your team's training