00:00:15.840
Beautiful! I am Krzysztof Kowalik, but you can call me Chris. Recently, I heard that researchers from Melbourne University conducted a study on people's names. They discovered that the more difficult a name is, the harder it becomes to maintain relationships, improve job prospects, and do other essential tasks. So, Polish people, maybe you should consider simplifying your names for the sake of foreigners. That's why you can just call me Chris. Feel free to find me on the internet; I’m on GitHub and Twitter. You can give me some love there. Don’t hesitate!
00:01:04.199
I’m from Poland, and it’s a great pleasure for me to speak in my motherland. Thank you for this conference; it’s fantastic that events like this happen here as well. However, one year ago, I moved to Uruguay. The reason is obvious, and I won't tell you much about Poland since everyone knows how it looks. Instead, let me share a bit about Uruguay: it has a lot of cows, about four times more cows than people. The locals, who can be likened to cowboys, consume a lot of beef, and they're crazy about tango and football.
00:01:23.640
At Kubok, a small software house in Uruguay where I work, we solve very complicated problems daily. We take maintaining broken builds very seriously and work hard—almost like a family. By the way, I have some gifts for you! I left them in my backpack. If you are interactive with us and start asking questions, your curiosity will be rewarded. I have some T-shirts featuring our products, so feel free to take part!
00:01:56.840
Speaking of myself, I am a Ruby enthusiast and high-scale systems are my passion. Some call me the optimization monster! I love what I do and enjoy putting my ideas into action through open source and collaborative work. You can read more about me on my website or my recently opened blog that discusses distributed computing and the Go programming language. I think you will find a good place for it in your bookmarks.
00:02:56.000
Today, I will be discussing distributed systems, but in a slightly different way than you might expect. Initially, I wanted to focus on tips and tricks for scaling applications. But do you really want to know how to build a larger system? Perhaps you'd like to learn more about having multiple systems instead.
00:03:06.480
This talk will be a bit more philosophical; it will address the 'why' of what we do instead of just the 'how.' It’s about finding the right attitude that good Unix programmers possess and understanding that life is a continuous journey of learning. Today, the tools you learn might become outdated, but I will share insights that are timeless.
00:03:29.440
The Unix philosophy, which has been around for about 40 years, remains one of the best solutions for programming challenges. I prefer to refer to it as the Unix Zen. Alan Kay famously said the best way to predict the future is to invent it. Meanwhile, Henry Spencer pointed out that those who don't understand Unix are condemned to create poor solutions, a truth I have faced repeatedly.
00:03:56.760
The Unix philosophy is particularly well-suited for current web development. In recent years, we've seen a shift: a few years ago, there was little need for distributed applications on the web. Most applications were small, but then web 2.0 emerged. People invented blogs, and social networks, and began having conversations online. Now, we are faced with the challenge of handling millions of users engaging with content, leading us to seek optimization solutions.
00:04:30.000
Reflecting on my early programming days, I didn’t grasp the Unix philosophy well. I tried to optimize every piece of code, resulting in systems that were complex, slow, and difficult to maintain. We all know that premature optimization is the source of all evil! The most powerful optimization technique in any programmer's toolkit is often to do nothing at all. Small components are often easier to scale, and therefore, each piece of the application should be well-constructed and function correctly.
00:05:09.000
I believe that monolithic applications must eventually fade away; they have no place in our current era of distributed applications. The cloud computing we have today and its advantages demand modular applications. Web services will take the place of monolithic frameworks in our pursuit of high-scale solutions.
00:05:46.600
What I've noticed is that many startups have relied on Ruby on Rails for rapid prototyping, allowing them to validate their ideas. However, a great number of these startups ultimately fail because they don’t need to scale. Those that do and must adapt tend to encounter further issues. The idea is that larger organizations have understood that Rails has its limitations. Rails is great for prototyping but not necessarily for everything, hence why web services have become the go-to solution.
00:06:35.600
You can see this in large systems where pieces of infrastructure are separated into smaller applications or microservices. This allows for enhanced scalability and better performance as each service can be independently optimized. My friends, keep it simple! Often, we don’t need oversized vehicles to navigate around the city; a small bicycle or rollers can do just fine.
00:07:13.080
Those who work with Rails often find themselves using outdated practices, functioning in a monolithic mindset. In contrast, progressive developers focus on building future systems while learning from the past. The best way to predict the future is indeed to invent it, and Unix will play a crucial role in that future as it has shaped so much of the present.
00:08:02.600
While I avoid over-optimizing now, I still follow the red-green-refactor cycle. First, we develop something that works, and only then do we optimize. Many fall into the trap of optimizing too soon. Measurement is key—only optimize when it is necessary.
00:08:42.920
Never tune for speed without validating the need! Run benchmarks, and better yet, implement isolated deployments with integration tests and adjustments for performance testing. Even if something is slow, avoid rushing to optimize it, as this can often lead to overcomplications.
00:09:28.160
Life isn’t about fancy algorithms; they are heavy and can complicate your setup. Instead, keep things simple where possible. Hiring skilled programmers can also be challenging; often, average developers will do. Thus, it's generally more efficient to maintain simplicity in your code while ensuring scalability.
00:09:58.680
Let’s make it clear! Cloud computing is the future, and it is something extraordinary. Many await powerful computers and quantum processing technology. However, these expectations are misguided. History has proven numerous times that clusters of simple Linux machines can outperform so-called supercomputers in both cost and efficiency.
00:10:33.760
Are you ready for the cloud? Are your applications ready to be deployed? Many people still deploy monolithic applications in cloud environments, and if you aim for the future, your applications must be cloud-ready, focusing on modular and easily scalable design.
00:11:00.080
For example, consider how we manage a bar. If a bar has only one bartender, everyone will be unhappy. However, if we scale operations by adding more bartenders, satisfaction increases. Similarly, applications should allow for the separation of high-load sections to be independently scaled, thus ensuring optimal performance.
00:11:45.760
Data is the most crucial part of your application, and I won’t go into specifics about how to choose the right database or tools. The information is readily available through simple Google searches. Ensure that you utilize caching; if any operation can be cached to avoid round-trips to the server, do it!
00:13:01.840
Nevertheless, we should not limit ourselves to one language. If another approach could yield better performance, do not hesitate to switch. It’s all about finding the right tools for the task at hand. By distributing tasks and focusing on smaller, specialized applications, we can achieve significant performance improvements.
00:13:45.520
Think about how users interact with your data. Building your systems with scalability in mind will pay off in the long run. Messaging systems should be employed to handle inter-service communication, rather than relying on databases as logs.
00:14:23.840
In conclusion, keep things simple, cache wherever you can, separate services appropriately, and remember the Unix philosophy. Spread the word about it, tweet about it, and write about it. It's crucial that novice programmers who lack a strong systems-oriented background realize that sticking to monolithic applications can be detrimental.
00:14:39.840
As I stated, the algorithms are not the main concern; it's essential to scale horizontally while allowing for modular updates without extensive system changes. Also, consider your data through the user's perspective rather than purely from a tech-centered viewpoint.
00:15:15.760
Finally, for those who have not read 'The Art of Unix Programming', I recommend it highly. If you wish to be successful as a programmer, you need to delve into these practices. There are also other notable books worth reading. Thank you so much for your attention. If you have any questions for me, feel free to ask.
00:21:06.240
I know I started by saying not to optimize prematurely and then discussed distributing everything. Those two ideas may seem contradictory. On one hand, I advocate for measuring first, yet distribution introduces problems that may complicate solutions.
00:21:47.600
However, it’s crucial to separate programming from business reasons. Monolithic applications may be fast to write but may not support high scalability. This shift comes into play once you validate your idea, and your users are engaging at volume. You will not build high-scale systems without distributing components into smaller, measurable pieces.
00:23:27.520
While I appreciate the utility of Rails, I believe it has added complexity over time, leading to less efficient applications. The future must focus on streamlining and removing unnecessary features. Tailor your approach to suit horizontal scalability, allowing teams to work more effectively on distinct system parts.
00:24:40.760
In closing, continue to develop your skills, consider the architectural choices that suit distributed applications, and ensure that you are always innovating as you learn. Thank you, and I look forward to your questions!