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.