00:00:14.160
Our next speaker gave one of the most visually horrifying talks I've ever seen. You know which one I'm thinking of. They're all like that actually. Well, I'm glad to share in that legacy.
00:00:21.640
At a conference at a water park in Northern Ohio, the only time I've ever been or will likely go to Northern Ohio, Chad gave a talk that was color-schemed in the style of McDonald's. Everything was neon yellow and red and it was a visual assault. I asked Chad if he could bring that presentation.
00:00:35.960
Does my 35 minutes start now? The bad news for you is that it started already. Alright, I have a personal note; someone who has given me indispensable advice over the years provided me with opportunities that changed my career and allowed me to change other people's careers. I hope you get to soak in some of the knowledge and expertise he shares with us.
00:01:00.640
So, thank you. Now, I would like to formally reject Jeff's clapping thing because they don't clap for me, but I just wanted to clap for all the talks today. They were really great.
00:01:06.119
Last year, I was part of a venture-backed company that was sold to Microsoft, and Sequoia was one of our investors. I follow various Sequoia Partners on Twitter, and last year I saw a tweet from one of the partners that said, 'Microservices is the next big step.'
00:01:13.000
This, by the way, is a big deal because they’re investors in Google and Apple, and it linked to a Wall Street Journal article that touted microservices as a huge business phenomenon. I thought to myself, this thing is over now. If you read the infographic they linked to, it became clear that they didn't even know what microservices really meant.
00:02:19.000
This year, though, in Berlin, I'm cashing in on the next big wave—small methods. Mark my words; in a couple of years, it’s going to be in the Wall Street Journal: small methods. We're going to have smallmethod.com. This is to say we should stop saying the word 'microservices.' Have you heard this word before? It's not even pronounced correctly; it's pronounced 'mrosich.'
00:02:32.920
I think we've ruined the concept of microservices by giving it a name and spreading it around. I work at Microsoft now; I hope those of you who know me are thinking, 'This is the least likely Microsoft employee ever,' but Microsoft is a good place. I work there because they bought our company, Wonderlist.
00:03:40.239
When I came into the company, people heard that we did this microservices thing, and they wanted to know how they could implement it too. However, they really didn't understand what it meant—it's just a word they've heard and it sounds good. These are really smart people, yet we’ve already destroyed this concept.
00:04:47.239
I've walked around the company and talked to these people. The real problem that plagues us all, and especially these people in this context, is coupling because we want to be able to change software. That's really the thing: we want to be able to improve things and adapt to changing business requirements.
00:05:08.600
So, we really want to reduce coupling in software, but Ruby is the worst language to use for that.
00:05:14.080
I wanted to mention Ruby because this is a Ruby conference. I've been using Ruby for around 16 years now, and when we started using it, there were very few of us. People would laugh at us and say it was a toy language, and we would talk about why it isn’t. It turns out it is a toy language, but it’s okay because you can use it for creating fun software, and that's what it’s all about. Ruby is great for playful exploration.
00:06:47.480
But you all have a code fetish; all the speakers today do. We keep talking about code. I was up there playing the ukulele with Jim, talking about code you know. Apologies for my ukulele solo; I was not on my game that day.
00:07:12.360
But code is not as valuable as it seems. Once you have code, you have legacy code; it becomes difficult to maintain. It's a liability to have code, but what you really want to build is a system that acts as an asset. I have a title for my talk: 'Impermanence, the Ironic Key to Systems That Survive.' Why am I talking about this? I started this sort of weird quest several years ago driving around Colorado with Corey Haynes, discussing the word legacy.
00:08:32.560
Why do we use the term legacy as a bad word? It should be a good word. As a musician, the concept of leaving a legacy is appealing; iconic figures like John Coltrane and Beethoven left a legacy. I have been thinking about how to create systems that survive longer than five years, the typical lifespan of software.
00:09:50.320
I was then recruited to become CTO at Wonderlist about three-and-a-half to four years ago, and when I arrived, we had an architecture that looked quite chaotic. It was unclear and disorganized, and many of you might have similar architectures in your organizations.
00:10:10.159
We went crazy and developed an architecture with about a hundred independent services, each deployed separately, talking via HTTP. We had a complicated system, and launched it in 2014. When we told our investors about it, you could hear the shock in their voices. They had been through this pain before countless times, and they didn't want to hear that we were rewriting the system.
00:11:07.559
I promised them it would be the last time, and while we did rewrite almost every single piece of the code since that release, the underlying system has not changed. That’s the important point: we rewrote the code but preserved the system. Creating systems that can survive requires understanding how to maintain change without creating unnecessary complexity.
00:12:42.400
I learned that a car can survive longer than many software systems. It operates merely because of balance among its parts. Also, the human body is a fascinating example—at 42 years old, I don't do any maintenance on myself yet somehow I still function. We regenerate constantly and don’t need our cells to live forever; it’s unrealistic.
00:14:41.720
I became fixated on the concept of everything being tiny, as did Fred George when he conceived microservices. Tiny components allow for easy comprehension; the complexity diminishes when things are small.
00:16:21.240
I spoke about this concept a few years ago at a conference and emphasized that keeping things tiny is key to building great software. Small components enable you to change them easily and replicate them consistently.
00:17:28.320
At Wonderlist, we implemented Chef for system management. In my previous experiences, I was proud of systems that remained operational for two years, but I now realize that long uptime is not sustainable since you can lose track of the state of the system. So, our new approach is to destroy the entire system and build anew whenever we need upgrades.
00:18:52.320
This method builds a system that’s inherently capable of continuous change, and it’s been successful for us.
00:19:00.720
We plan to throw old code away when necessary rather than enduring the stress of trying to update it.
00:19:05.960
Our approach at Microsoft is to recognize that the code can be older but constantly evolving; we avoid attachment to the legacy ideas.
00:19:17.880
The key point here is that our company, Wonderlist, rewrote a significant percentage of our code without it being counted as a formal project.
00:19:28.440
Instead, it was a part of regular maintenance work to ensure the system's health and continued operation.
00:19:39.680
Doing this keeps us agile; for instance, we could go from running thirty servers on Ruby to three servers on Scala, simply because we found a better tool for the job. It allows us to adapt and improve continuously.
00:20:51.480
We also allowed team members to work with any language they prefer, which means they could adapt easily to changes. This promoted a culture where individuals frequently changed from one language to another without hesitation.
00:21:55.600
We prioritized the decoupling of code and components, urging that shared code often creates unwanted coupling while implementing shared services running locally.
00:23:09.640
Our services communicate via simple HTTP requests and JSON. This simplicity made it easier to understand the system better than with complex protocols. Efficiency became a secondary goal compared to understanding.
00:24:21.240
We tracked metrics to validate our decisions in real-time, focusing on performance indicators, monitoring how users interacted with our applications to ensure they benefited from our services.
00:25:32.600
So, a lot of my experiences led me to the insight that organizations, like our software systems, should also remain impermanent.
00:26:43.360
Management structures should evolve and adapt, and often need to be restructured to prevent stagnation. Indeed, significant change indicates overall health within an organization.
00:27:55.360
Small projects and teams tend to succeed more often since they're more adaptable. Teams should form, create, and reconfigure in impermanent cycles, maintaining a status of flexibility.
00:29:27.360
While many may fear the change from a traditional structure, it would be more prudent to always be willing to accept new ideas and ways of working, empowering team members with trust in their skills.
00:30:45.720
In closing, understand that microservices is not an architecture you can transition into; it’s a concept. The goal isn't to adopt microservices for their own sake, but to reduce coupling, promote change, and ultimately enjoy the process.
00:31:47.720
Remember, small should not be the sole goal. Healthy longevity is key—if you make your systems flexible, they will adjust to changes better over time.
00:32:54.600
Now, I will answer questions before you awkwardly applaud. In your face! Oh yes, all of you will be replaced like microservices have been.
00:35:07.480
I see some hands raised for questions.
00:35:14.720
Hi, I worked in a place once where the manager said you can use a new language only if you can convince another team member to use it as well. In your view, is this similar to the jack of all trades idea?
00:35:23.960
You are correct; it can mean you might not have experts in each language used in production. However, usually, there’s one or two passionate advocates that balance it out.
00:35:38.880
In my experience, exposing oneself to a variety of languages has taught me to match patterns at different abstraction levels without much hassle in production.
00:36:06.240
I see we also have someone wanting to ask a question. Please go ahead.
00:36:29.440
My experience involves many people not sharing your passion for change, leading to stress. What are the social pressures or stresses that come from rapid changes?
00:36:40.960
Changes in code can be emotional, and to combat that, we've made it a part of our culture to celebrate every code replacement to reinforce its normalcy.
00:36:56.760
Let’s give Chad a tiny clap on the count of three: 1, 2, 3! Thank you!