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
Continue reading …
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.
Then Grindr’s Principal Applications Engineer Tom Bray walks us through “Going Serverless with AWS Lambda”:
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!
Continue reading …
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.
Continue reading …