Panel: Enterprise Rails

Nick Sutterer

Nick Sutterer

@apotonick

Andrzej Krzywda

@andrzejkrzywda

1 more speaker

See all speakers

#event-sourcing

#domain-driven-design

#microservices

#ruby-on-rails

#performance

#software-architecture

Panel: Enterprise Rails

by Nick Sutterer, Andrzej Krzywda, and Nathan Ladd

The panel discussion titled 'Enterprise Rails' features experts Nick Sutterer, Nathan Ladd, and Andrzej Krzywda at the wroc_love.rb 2018 event. The main theme revolves around building and maintaining enterprise applications using Ruby on Rails, focusing on the unique challenges that arise in a professional context. The discussion begins with the identification of potential pitfalls in Enterprise Rails projects, emphasizing that losing control over the codebase can lead to business failures. Key points include:

Definition of Enterprise Rails: Defined as applications used by various company departments that frequently require structured interaction, highlighting the difference between enterprise and startup software.
Challenges with Active Record: The complexities of Active Record can hinder maintainability as applications scale, making it difficult to manage changes coherently.
Importance of Maintainability: Enterprise Rails emphasizes the need for maintainable systems, foreseeing infrastructural complexities typical in larger applications.
Tooling and Frameworks: Discussion on tools like Eventide and Rails Event Store and their role in managing complexity without reinventing the wheel. The need for standardized tools versus custom solutions is critiqued.
Distributed Systems Understanding: As systems grow, understanding distributed systems becomes essential. The need to handle issues like idempotency and concurrency is particularly stressed.
Community Engagement: Highlighting the Rails community's evolution and the importance of embracing shared architectures for application success.
Architectural Principles: Introduction to the implications of domain-driven design and the transition within the software development landscape.

In conclusion, the panel encourages developers to cultivate an appreciation for thorough architectural coherence and event-driven designs to build robust, stable, and maintainable software systems. Fostering collaboration within the community and sharing knowledge is presented as crucial for advancing the craft of software development, aiming for a vibrant Ruby ecosystem that adapts to evolving technology demands.

00:00:23.910 Okay, let's start our panel discussion about Enterprise Rails. Please meet the experts: Nitin from Eventide, Andrzej from Rails Event Store, and Nick from Trailblazer.

00:00:30.570 There are a few questions you can still add more queries to the gist. I will try to ask them.

00:00:39.540 The first question is: What are the worst things that can happen in Enterprise Rails projects, and how can you protect against them? I mean, you’re the experts here, right? Running a company, what do you think?

00:01:05.220 The worst thing that can happen is no longer earning money, which usually results from being unable to maintain the system or keep it stable and running. By definition, Enterprise Rails refers to applications that start making money as opposed to startups. Often, when there are complicated business processes that you need to maintain over the long run, you have more programmers involved. The risk comes when you lose control over the codebase.

00:01:33.479 So, what exactly is considered Enterprise Rails? I wonder what the precise definition is. From what I see, once your company has various departments and your application is heavily used, this doesn’t necessarily mean you need a large number of users, but it does mean that people are using it frequently, and the organization becomes more structured.

00:01:59.490 There used to be a strong sentiment in the community against Enterprise software, often emphasized by David Heinemeier Hansson. While he aimed for a punk ethos, perhaps he chose the wrong terminology. Enterprise software, according to Wikipedia, is defined as software intended for more than one user. Anyone can edit Wikipedia, and while it’s democratic, it’s also misleading at times.

00:02:46.889 The worst thing that can happen in Rails, especially in the context of Enterprise software, is issues with Active Record. To clarify, Active Record's complexities can become challenging to manage when the application scales. The general question we’re addressing is: Enterprise Rails involves using Rails in a professional environment where the software is maintainable and enjoyable to work with, which is crucial for job satisfaction.

00:03:53.060 However, certain frameworks can prove hard to deal with once the complexities arise. If you haven’t partitioned your system, you'll run into issues common in enterprise systems, such as slowdowns, making changes difficult, and maintaining a clear understanding of your codebase. If your system isn’t partitioned, you will struggle with updates since changes in one part often necessitate changes throughout the system, including data migrations and cleanups.

00:05:00.650 At its heart, my understanding of Enterprise is about building a maintainable system. Yet, managing Rails and maintainability is tough because as a system grows, it becomes more complicated. Enterprise implies success, meaning your application cannot just be a single page for a coffee shop; it involves handling more than 100 active records, which in enterprise terms is quite small. The whole concept of Enterprise Rails applications involves not just making money but also handling the influx of users.

00:05:49.219 When we consider our presence in the Rails community, we need to recognize that developers are writing Enterprise software; everyone here has experience with software for more than one user. So, where are we right now in this community? The discussion aims to bring together people responsible for the tooling, as Trailblazer has been a player in the community for a while.

00:06:50.369 Nathan is responsible for Eventide, which is a great project, and we should explore how these tools interact. I think the idea here is to look at stability improvements over the past five years, and how we can further support developers in this landscape. Many companies are still opting for the pure Rails way, while others build their own tooling, or they use existing frameworks like Eventide and Rails Event Store.

00:07:25.570 There's a term I want to clarify: Enterprise implies using tools that are actually available rather than constantly rebuilding solutions. There’s a distinction between established tools with standardized interfaces—such as form objects or service layers—and the variety of approaches out there which can lead to a lack of consistency.

00:09:05.100 The challenge becomes ensuring we know how to effectively use tools to build distributed systems while understanding fundamental principles about architecture, like bounded contexts in domain-driven design (DDD). This transition requires us to consider how we cultivate a community that appreciates the depth of what we build rather than opt for surface-level solutions.

00:09:40.610 Indeed, large systems in special industries, such as banking and healthcare, do not operate solely in a web context. There comes a time when one must see their application not just as a web development project but as a comprehensive software development endeavor where web functionality is only a facet of the greater system. To have a vibrant Ruby community, we should address software development in its broader context.

00:10:34.999 Part of this means examining if Rails' MVC architecture is sufficient for building successful Enterprise applications. Personally, I believe it's not enough since actual enterprise projects often involve more than just the MVC confines. It’s about whether you can decouple your application from Rails and still operate effectively outside a web environment.

00:11:28.890 The minute you start splitting your application into smaller parts and introducing process boundaries—whether through threading, UNIX processes, or microservices—you will encounter distributed systems problems. It’s imperative to be ready for these complexities, and teach developers the realities of working within these models, ensuring they understand the robust nature of distributed systems.

00:12:35.950 While we might wish to avoid issues such as idempotency and concurrency, being prepared for them is crucial. It’s easy to make a disastrous system with any tool, including Eventide, which necessitates understanding how distributed systems operate. The objective isn’t to create a magical solution; rather, it’s to empower skilled developers to build reliable systems.

00:14:01.230 The problem with many in the software world is a tendency to avoid hard challenges by relying on convenient tools, leading to poor implementations. Tooling should enhance understanding, but solutions cannot replace fundamental principles. Many are tempted to oversimplify complex problems, and we have to push back against this trend.

00:14:43.730 Both Eventide and Rails Event Store serve as platforms for building systems designed to tackle these challenges, providing feedback and support for developers. The essence lies in teaching developers how to convey messages safely between systems while also enabling historical insights from the events processed, maximizing data value.

00:15:50.600 The engagement we see now stems from the community’s realization that infrastructure design based on event-driven architectures delivers better robustness and scalability when built correctly. The differentiated understanding of state management in distributed systems ultimately drives us towards better software design across various programming languages.

00:16:41.830 Platform discussions have evolved, just as deploying Rails applications have become more intricate. The evolution of deployment methods, from Passenger and Puma to modern cloud solutions, reflects what’s essential for managing enterprise projects in a changing environment.

00:18:27.180 To conclude, the abstract ideas we discuss may not be entirely new, but they underline a trend alongside our ongoing evolution as Ruby developers in utilizing shared architectures for the success of our applications. With distributed computing and messaging at the core, developers must embrace the realities of a changing technological landscape and identify how these methodologies can inform our practices.

00:19:40.280 It's important to foster environments where knowledge sharing takes place. Collaboration among various ideas within event sourcing serves to augment individual projects and threads through our enterprise journey, shaping maintainable and adaptable software.

00:20:03.660 This transition to understanding how powerful events in messaging systems can be fosters an appreciation of architectural coherence, leading to softer, more streamlined applications. It isn’t merely about tooling; it’s about cultivating systematic thinking in how we apply design patterns across projects.

00:21:02.250 Engaging with patterns like domain-driven design can help us bridge gaps in knowledge and serve as a foundation for building more robust systems tailored to our requirements. Our goal is to critically assess the landscape and chart a path forward in creating stable, maintainable software.

00:21:28.910 Thank you very much for your participation today! Let's work together to foster a vibrant community centered on advancing our craft and defining trends that will guide us into the future.

wroc_love.rb 2018