Microservices

Summarized using AI

Kill "Microservices" before its too late

Chad Fowler • October 19, 2016 • Earth

In the talk titled "Kill 'Microservices' before its too late," Chad Fowler discusses the problems associated with microservices in software development during the Rocky Mountain Ruby 2016 conference. He outlines his perspective on how the term 'microservices' has been misused and misconstrued, leading to misunderstanding among many developers and companies.

Key points include:

  • Misinterpretation of Microservices: Fowler believes the term 'microservices' has lost its meaning, with many organizations trying to implement it without understanding its true essence, causing inefficiencies.
  • Decoupling and Flexibility: The essential goal in software development should be to reduce coupling to allow for greater flexibility in adapting to changing business needs.
  • Legacy Code: He challenges the negative connotation associated with legacy code, positing it can be viewed positively if managed correctly. Fowler argues that code should be treated as an asset, not a liability.
  • Impermanence in Systems: Fowler emphasizes that successful software systems should embrace change and impermanence, much like natural systems do (e.g., a car or the human body) to maintain health and efficiency over time.
  • The Role of Small Components: He highlights the importance of small components in software design, suggesting that they are easier to manage and facilitate a more agile development process.
  • Adapting to Change: At his company, Wonderlist, Fowler promoted the practice of replacing old code with new solutions, ensuring that the system could continuously evolve without the burden of outdated legacy systems.
  • Cultural Shifts in Organizations: He advocates for a culture that embraces change, suggesting that management structures and team configurations should be adaptable rather than fixed.

Chad wraps up his talk by reinforcing that microservices should not be a goal in itself, but rather a means to achieve greater flexibility and adaptability in software development. The final takeaway is that a healthy software environment should allow systems to adjust and thrive over time, making impermanence a fundamental concept in the design and management of these systems.

Kill "Microservices" before its too late
Chad Fowler • October 19, 2016 • Earth

Kill "Microservices" before its too late by Chad Fowler

Rocky Mountain Ruby 2016

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!
Explore all talks recorded at Rocky Mountain Ruby 2016
+3