00:00:11.960
Cool, so thank you guys for coming. First of all, my name is Taylor Jones. I'm going to talk about architecture and what’s coming next. However, we need to view a couple of frames before we figure out exactly what is next.
00:00:24.330
Again, I said my name is Taylor Jones. You can find me on the internet under 'Hi, I'm Taylor Jones'. I grew up in a really weird state called Alabama, and then I decided to move to an even stranger state called Florida. So now I live smack dab in the middle in Orlando and I love it.
00:00:41.120
On the internet, I write stuff for people like Code Ships. My personal site is 'Hi, I'm Taylor Jones', and I just write a bunch of random stuff on Twitter if you’re interested in that too. This talk is not about Star Trek, so I apologize if I have a few things in there, but we’re not going to delve into the whole history of it.
00:00:58.620
Anyways, I work for a company called Isaiah in Orlando, and we do a lot of really interesting stuff. For one, we do content marketing; we also do a lot of social media, general data analytics, and provide enterprise solutions to marketing systems.
00:01:12.900
We have a big pile of data and we’re trying to organize it and draw conclusions from it. Honestly, we all have this kind of data; for us, it’s social media data. We depend on a lot of external APIs like Facebook, Twitter, Tumblr, and any kind of popular social network. We’re trying to mine metrics and data from it to provide that information to folks who want to create content.
00:01:38.810
As far as the tools we use, we use a lot of Rails and Ember.js. What that means is that our stack is very focused on this convention over configuration approach. However, we also incorporate a good bit of Java and Python into our stack as well. That being said, the balance of our stack is always changing and we’re always trying to explore something new.
00:02:02.100
I think DHH had a wonderful analogy the other day, discussing how we adapt but also swerve every once in a while to figure out what’s new and why it matters. This talk is mostly about Rails architecture—where it’s been, where it’s going—and we’ll also discuss technical debt and how architecture can create or relieve it.
00:02:30.270
Isaiah has technical debt, your company also has technical debt, and we must figure out how to address it. I believe that architecture is at the root of a lot of our technical debt. This may seem like a loaded statement, but I mainly mean that it determines the means by which our technical debt accumulates.
00:02:59.100
So how exactly does architecture create technical debt? We often become too focused on building features that we forget to clean up our messes. Fixing technical debt is often viewed as unprofitable. It’s true; our stock isn’t going to rise every night simply because we said we’re addressing technical debt. People want to see features shipped and want to see whatever’s new and exciting.
00:03:40.110
But has it always been this way? Does modern architecture create more debt? Have we somehow forgotten lessons from the old days, losing insights along the way? I think it’s important to look back at our past and see if we can find something within it. What was the early web like? Well, applications were hard to deploy, code organization was inconsistent, and development and live environments were hard to duplicate.
00:04:15.299
These problems still exist; none of these issues are completely solved. However, if you look back five or ten years ago, they were probably twice as hard as they are today in a lot of instances. So then, during this era of the web, a thing called Rails appeared, which was interesting because it employed the idea of convention over configuration.
00:04:40.920
What this simply means is that it eliminates tedious parts of development, like setting up environments and scaffolding. It allows developers to focus on the things that matter, which is crucial when trying to quickly iterate and deliver new features. In short, it reduces a lot of unnecessary work in the web development process.
00:05:08.150
That doesn’t mean that refactoring is automatically good, though. We can perform good refactoring, but we can also make really poor refactorings in our minds. So what kind of research should we think about with Rails? This is a picture of my cat.
00:05:41.520
But we do need to examine how Rails has evolved to understand this better, as I think there are some important patterns to recognize. If you look at the origin of Rails, you see it was based on the existing product developed at Basecamp, and it had a real-world use case by default. So the creators of Rails took the ideas that worked for them and made them available to the wider community.
00:06:08.700
However, as it started to grow, some folks decided to create a framework known as Merb. Merb was a reaction to a lot of problems in Rails. It was developed within the Ruby community and aimed for a cleaner implementation. So, while the original Rails was an extraction of a product and some ideas, Merb focused on speed, scalability, modularity, and API tools.
00:06:43.169
Eventually, Rails and Merb decided to merge, resulting in Rails 3.0. It was a bit messy at times, but ultimately I believe it was beneficial for the Ruby and Rails communities because it united them under a common framework and community. One of Rails' strongest attributes is indeed its community that genuinely cares.
00:07:26.799
As a result, some ideas that were presented about frameworks didn’t survive due to binary decisions on how to handle certain parts of what became Active Record. After the merger, Rails began to learn from the formation process, implementing lessons it had learned during its evolution.
00:08:06.410
One thing I find really interesting about Rails is how it broke apart the general Active libraries, turning them into their own gems. So when you bump to a new Rails version, you're often just bumping those gems, which is really cool. Additionally, Rails 5 introduced API mode, making it simpler to build APIs.
00:08:40.800
As time went on, however, architecture became slow and messy, which made maintenance a pain. What this means is that we have to recognize code smells, bad patterns, and other harmful things that can arise in our applications. This isn’t easy; no developer enjoys saying that they're shipping awful code.
00:09:21.450
A couple of years ago, I conducted some research for this; it was my first real conference, actually. I was a long-time listener and a first-time caller, in many ways. I referenced Robert Martin, whom I admire, who noted long ago that one of the issues that Smalltalk dealt with was its messiness, leading to the demise of its community. This is applicable to many languages, including Ruby.
00:10:00.310
We have to be cognizant of keeping our code clean because a mess can lead to big performance bottlenecks. If you haven’t made a mess in Rails, I highly recommend it; it’s a great learning experience. Examples of messiness could be a lack of distinction between models, views, and controllers, leading to bloated controllers or messy view layers.
00:10:55.320
As Rails grew, it began addressing many issues affecting the community. This involved making the framework more modular, efficient, and scalable. I think this is primarily what has led to Rails’ success; the community has said, 'This is a problem, let's address it, and let's move forward together.'
00:11:32.280
Despite this, the question arises: is Rails as useful as it used to be? It used to be a highly popular all-in-one solution, but the Internet is weird, and many write blogs claiming it is dead or redundant. So, do we just go home and do something else? I want to share an interesting story about Twitter’s choice to move away from Rails.
00:12:20.040
Twitter became a big deal overnight and became the poster child of Ruby on Rails. However, they eventually moved away from Rails. There were rumors and speculation about why they made such a change, but many believed it stemmed from frustrations with the framework when rewriting their search engine.
00:12:59.340
They had issues with how Rails managed data and how it queued their database calls, leading them to gradually phase out their Rails components in favor of building new services in other languages. They were breaking down a larger application into unique services that worked together, which is a common theme in microservices architecture.
00:13:43.200
A great example comes from Netflix, which, although it hasn’t heavily used Rails, has become an advocate for microservices. They have built a remarkable architecture that can deliver high-quality HD content efficiently. They can choose any language for smaller services, benefiting from the flexibility and scalability that this approach offers.
00:14:51.480
This leads to the question: how do you test all the pieces you’re building? Netflix developed the Simian Army, a set of testing standards meant to exercise various aspects of their microservices architecture. The Simian Army creates high-stakes scenarios for developers, taking down production instances if they don't meet specific standards.
00:15:41.940
The main takeaway here is that when we change our architecture, our processes and understanding must adapt. We trade the comfort of what we know, such as maintaining a monolith, for a potentially brighter future with microservices. But every architecture is a brave new world, and if done incorrectly, it could seriously hurt our businesses.
00:16:32.380
How do success stories like Netflix and Twitter fund their successes while transitioning their architectures? I want to discuss what it means to actually design certain patterns in Rails. For one, we have monolithic versus microservices designs. Monolithic designs encompass connected pieces within an environment, sharing data easily.
00:17:18.900
In contrast, microservices require you to build unique, independent services that may operate under a more rigid interface. Rails, when functioning as a monolith, has always skewed towards a connected model.
00:18:06.020
As we process increasing amounts of data, we quickly recognized the need for better architecture. We began using tools like Sidekiq to manage this growth effectively. But on exploring AWS, we began a journey toward microservices, discovering independent components that function together but still rely on the larger application.
00:19:11.250
Now, microservices promote modularity and loose coupling. My research indicates many teams exist in a combined state between monolithic and microservices approaches; we maintain a large Rails app while also integrating microservices.
00:19:52.240
This results in a microservices ecosystem engaging both monolith and microservices traits, allowing us to have pieces that are independent yet tightly coupled.
00:20:03.889
For example, with Docker, you can create small containers for your applications and databases. Using Docker-compose allows you to orchestrate these pieces effectively. The beauty of AWS lies in its flexibility, letting you utilize various services while controlling them easily.
00:20:52.260
I believe Rails is like a microservices ecosystem, given that we have modular pieces with some tighter coupling. We’ve worked towards making parts of Rails independent and customizable, pushing toward a future where we can utilize various languages effectively.
00:22:00.940
You might say, 'I see your point, this is great for understanding microservice systems, but how do we transition?' One key step is to kill the hype around specific technologies. Shifting architecture demands we leave biases behind and evaluate based on practical needs rather than trends.
00:22:43.910
A difference exists between implementing something small and placing it into production. It’s essential to be excited about new technologies but also to be skeptical. Each method comes with a balance suited to each group of people, considering your architecture's suitability to your team size and skillsets.
00:23:28.050
If you are a small startup with three developers, don’t chase twenty microservices in different languages—it’ll be hard to maintain! Find your pacing, and recognize that changing your architecture means changing how your development process operates.
00:24:07.690
Knowledge is power, and you have to ensure that your team is on the same page. Disparities in learning can create disconnects, so fostering an environment where developers can share experiences is crucial. I've witnessed teams where some people excelled at teaching but no one wanted to learn or vice versa.
00:25:06.640
To ensure effective knowledge sharing, limit the number of decision-makers in design discussions. Assemble a small core team and craft a design proposal before getting feedback from a more diverse engineering team. This way, you can refine your idea while incorporating various perspectives.
00:26:00.750
Effective developer teams are those with a desire to learn. However, you don’t always have the same motivation across the board. It’s essential to provide space for developers to grow without the fear of them moving on after gaining new skills.
00:26:34.300
Architecture, in many ways, is like a house that collects clutter. For example, Spaceship Earth at Disney is its own piece of unique architecture—it collects dust and clutter just like our projects do. Acknowledging this is crucial for our development environment.
00:27:16.080
Technical debt can become a challenging issue, as demonstrated by Twitter's experience. They found themselves painted into a corner with a large user base and overwhelming issues that prompted them to abandon Rails in search of a better solution. We must learn to maintain cleanliness in our architecture.
00:28:05.760
Finding a balance that allows addressing debt while pushing forward features is crucial. You’ll never find a perfect time to halt development completely to fix technical debt. Instead, we need to integrate it into our development cycles, slowly cleaning up as we advance.
00:28:51.900
Architecture should prioritize developer happiness. People shouldn’t switch to microservices for trends; rather, they should pursue what enhances their effectiveness. Emphasizing happiness in architecture should be a cornerstone of developer-centric approaches.
00:29:30.000
With the lessons from the past and present, what's coming next? I don’t have a definitive answer but examining our history of Rails and changes in architecture shows a back and forth between monoliths and microservices.
00:29:40.000
The pendulum is swinging toward more modular microservice architecture, but it’s uncertain where future developments may lead us—like the potential of web assembly, for instance. Regardless, I genuinely enjoy being a developer and look forward to the possibilities the future holds.
00:30:15.540
Thank you guys for coming along! We’ve got about five minutes for questions; if not, we can discuss later.
00:30:38.420
How do we manage technical debt while working on features? It’s challenging, and often it comes down to changing the environment in your workplace.
00:30:54.330
A practical example might be using Test-Driven Development (TDD) where we demonstrate that writing tests, creating code, and refactoring can combat technical debt.
00:31:04.230
So, we might designate an hour of every development cycle to clean up technical debt while simultaneously building features. Recognizing this need from a leadership standpoint greatly contributes to the overall cleanliness and effectiveness of the architecture.
