RUG::B

It is a very simple set of recommendations on how to build a ruby app in a product-oriented style. How to define and split business layers' knowledge responsibilities and how to avoid violation of these rules.

Going from a monolithic architecture to microservices is never a "big bang" migration, you need to keep delivering features to your users so services are extracted as the need arises.

During the transition, teams deal with both the monolith and microservices. The differences in technology and delivery process for both, combined with the decreased attention the monolith receives can decrease the confidence level, slowing down delivery and even planned microservice extractions.

How much to invest in the original monolith? Too little can lead to teams avoiding it, too much means wasting resources in a deprecated component.

This talk summarizes the experience of containerizing our monolith to run it in the same infrastructure as our microservices, using the same delivery process. How this improved confidence in delivery, how it simplified operations and how it enables us in current initiatives like our multi-datacenter architecture. Also, which problems we encountered along the way.

Naming is hard — but at a previous company I worked for, the naming problems were more than just annoying.

In this talk, I will run through a handful of examples of bad naming. You’ll see how bad naming can have non-trivial effects. I’ll formulate a set of principles of naming, which are indispensable for any well-running tech team.