In our last Domain-Driven Design discussion, we learned how to group similar business components into application Bounded Contexts, which were separated folders in our Rails apps. This segregated cohesive groups of application code into separate folder structures (bounded contexts), and gave us a jumping-off point to drawing more explicit boundaries between domains in our monolith. Now it’s time for us to re-think how to communicate from one context to another. Here’s how:

Monolithic applications are great when you start building your company, but as time progresses, they become difficult to maintain. These codebases, as they grow, easily become Big Balls of Mud.

When building large applications in frameworks like Rails, the very convention-over-configuration design principles that made Rails such a joy to use begin to get in the way when the application grows in scope. You may be experiencing the same pains as well if:

Refactoring is difficult and tedious, because methods and classes depend on too many other classes

You have an ever-growing list of business objects that are difficult to keep in your head. In fact, nobody seems to be able to understand the system as a cohesive whole

Changing code in one area of the code leads to unexpected and unintended side effects in other areas of the code, because it’s easy to call out to global services and objects

The micro-services push is on with developers writing simpler applications that interact with each other. But how do you deploy these services? Manage versions and discoverability? Learn two approaches from our August 17th Talk Night speakers as they cover using Docker or going completely server-less with Amazon Web Services’ Lambda!

First we’ll have Samuel Chow, Head of Mobile at Farmers Insurance, give an “Intro to Docker”:

Docker has become one of the hottest technologies in the industry. But what is Docker? Why do developers love it and why might you want to use it? We will cover how it works and introduce the Docker terminology and toolset.

Microservices got you down? Come learn how to implement Serverless architectures with AWS Lambda and API Gateway from someone who has done it in the real world. Get a glimpse of life beyond the operational overhead that Microservices require and discover the benefits of Serverless. Decrease time to market, reduce operational cost, and let AWS Lambda handle scaling for you automatically while you only pay for the compute you use.

Our doors will open at 6pm with pizza, drinks (including non-alcoholic options), and of course wi-fi provided. The talks will kick-off at 7pm, with Q&A interspersed throughout.

So sign up on Meetup and get ready to get some macro-knowledge on building micro-services!

You’ve resolved to build your company’s Next Big Thing in Phoenix and Elixir. That’s great! You’re facing a problem though – all user authentication and access concerns are performed on your Rails system, and the work to reimplement this in Phoenix is significant.

Fortunately for you, there is a great Phoenix plug to share session data between Rails and Phoenix. If you pull this off, you’ll be able to build your new API on your Phoenix app, all while letting Rails handle user authentication and session management. Let’s get started!

Your Rails application has become a monolith. Your test suite takes 30 minutes to run, your models grow to several hundred (or thousand!) lines, and feature development slows to a crawl. New members of your team must read through massive amounts of code before they can feel confident making changes. You’ve watched Uncle Bob’s Architecture the Lost Years, Matt Wynne’s Hexagonal Rails and read Martin Fowler’s Microservices and are convinced that the time has come to start breaking things up into smaller, simpler, faster components – but you’re unsure of where to begin.

In this article, I will demonstrate an approach to breaking a monolithic-style Rails application apart into microservices using plain Ruby classes and a simple RPC framework – all deployed to Heroku. I’ll show you how to work through this migration incrementally; you’ll be able to decompose things down as far as makes sense for your codebase. As a special bonus, I’ll show you how you can use Barrister RPC to alleviate much of the pain associated with documenting and creating API clients for the components of your now-distributed system. I’m skipping the advocacy; if you’re here it’s because you already love yourself some microservices but don’t know how to implement them yourself.

Carbon Five is a full service software consultancy that helps startups and established organizations design, build, and ship awesome products. If you have a project you’d like us to take a look at, or are interested in joining our team, please let us know.