Fallacy of Assuming Reuse Equals Efficiency – Leveraging Microservices for Experimentation
•Download as PPTX, PDF•
0 likes•89 views
The DRY principle of Don’t Repeat Yourself has been one of the commandments of software engineering, ever since The Pragmatic Programmer book in 1999. A lot of things have changed since 1999, however. Microservice Architecture is directly questioning supremacy of “reuse”, advocating to prioritize “replaceability and upgradeability over reuse”. We will explore whether reuse of code, model and design are still always a good idea, especially in large, enterprise applications built with a microservice architecture. We will provide concrete guidelines that we have used in our work to decide when reuse should be prioritized vs. de-prioritized.
Recommended
Recommended
More Related Content
More from Nordic APIs
More from Nordic APIs (20)
Recently uploaded
Recently uploaded (20)
Fallacy of Assuming Reuse Equals Efficiency – Leveraging Microservices for Experimentation
- 1. inadarei Rethinking Code Reuse Leveraging Microservices for Experimentation Irakli Nadareishvili, Sr. Director, Capital One.
- 2. inadarei
- 3. inadarei - Life’s Little Instruction Book, H. Jackson Brown Jr.
- 4. inadarei
- 5. inadarei
- 6. inadarei Manufacturers of such doors are trying to create a door that can be “pushed or pulled” from both sides, so it’s reusable no matter how you install. Designing for unknown reuse - sounds familiar?
- 7. inadarei 11 Insisting on “Reuse” as an ultimate goal leads to lowest common denominator solutions
- 8. inadarei Photo: P-51 Mustang of 361st Fighter Group, 1944. Wikipedia No one is even close to the “normal” persona based on average of multitude of characteristics.
- 9. inadarei 11 If you’re always trying to be normal, you will never know how amazing you can be. Maya Angelou (1924-2014) ”
- 10. inadarei VS.
- 11. inadarei CAUTION: 1. Advertising – Information propagation 2. Proper sun-setting of non-competitive products.
- 12. inadarei CAUTION: 1. Enforcing reuse can be just as costly. 2. Local cost is a bad optimizer. Only overall Throughput matters. 3. Dependency (on a centralized solution) has non-linear costs.
- 13. inadarei
- 14. inadarei 1. Ben Christensen: “Standardize Protocols and Contracts” 1 2. Mike Amundsen: “Share Vocabularies, not Data Models” 2 3. Reuse of widely-adopted services is usually fine. 1. https://www.youtube.com/watch?v=-czp0Y4Z36Y 2. https://twitter.com/mamund/status/767212233759657984?lang=en 3. https://medium.com/capital-one-developers/rule-of-twos-and-microservice-architecture-3f57db7f6896
- 15. inadarei
- 16. 11 Microservice architecture is the implementation of your system. It is not the public API interface of your system that external or most internal clients should depend directly on.
Editor's Notes
- Let me tell you a little bit about myself. I work at Capital One, where I lead microservices transformation efforts. Microservices is an area that I am quite passionate about because it unites multiple other things I love: APIs, distributed systems, containers, organizational design and team culture. I have been building microservices for several years now and in 2016 we published a book about microservices, with several friends. Today I want to talk to you about one of the hotly debated topics in Microservices, which is – code reuse.
- You see, reusing code, reusing APIs has traditionally been viewed as the road to efficiency However, a lot of microservices practitioners actually question whether reuse is always a good idea, instead prioritizing replaceability and upgradeability, over reuse. This may feel like a fallacy to you, because the DRY principle of Don’t Repeat Yourself has been one of the supreme commandments of software engineering, ever since Andy Hunt and Dave Thomas published The Pragmatic Programmer book in 1999. A lot of things have changed since 1999, however. So please indulge me in going on a journey with you to explore whether reuse is always a good idea.
- Let’s start by discussing some design principles. How many of you have been confused by whether you should push or pull a specific door? Raise of hands, please! Well, I have very good news for you – it’s not you, it’s the doors. Specifically the badly designed doors often referred to as “Norman Doors”,named after the famous designer Dan Norman, who first identified the poor usability of everyday products in his classic book Design of Everyday Things. Specifically, the problem on the photo is that a door that is supposed to be pushed has a handle. Handles indicate pulling. These doors communicate false information about their capability.
- A proper ”push” door should have flat surface or a pushbar, making it clear that the ONLY thing you can do with such door is to push. There should be no confusion.
- Now, it’s too easy to assume that the designers of Norman Doors are just stupid. In reality it is not always the case. They didn't design the doors out of spite of human race, what they were probably trying to achieve was to manufacture a door that can be “pushed or pulled” from both sides, so it’s reusable no matter how you install it. This is designing for presumed reuse - sounds familiar? And yet it led to object so frustrating and useless that a famous designer wrote a book about it. Ouch! Photo credit: Sutterstock with proper license
- When you make reuse the ultimate goal, you will end-up designing for an average user and end-up creating lowest common denominator solutions.
- Sometimes designers call the averaged persona a “normal user” to make it sound better, but designing for such “normal” user is still very misleading and can even be life-threatening, as US Air Force learned the hard way in 1940s. They tried to design a cockpit of a fighter airplane based on averages. The results were devastating. The performance of top pilots became abysmal. See the problem was that no one is ‘normal’. Everybody is made up of a multitude of individual characteristics: height, weight, length of the hand, ratio of upper and lower body, feet length etc. Averages sortof work for single variable, but if you take an average across multiple characteristics, you won’t find any individual who is even close to the “normal”, in all respects. This is known as the ‘jaggedness principle - averaging across multiple variables doesnt work. When US Air Force designed the cockpits around average range of 10 body measurements across 4,000 pilots, they ended up with a design that didn’t fit well anybody. It was uncomfortable for EVERYBODY. Because they didnt take into account juggedness principle. They ended up inventing adjustable seats, which is why we also have them in our cars now.
- Remember Maya Angelou’s words: "If you’re always trying to be normal, you will never know how amazing you can be."
- Aside from problems with averaging, another issue is that reuse can kill innovation. If you always only have one choice – how do you foster innovation? A market with no competition doesn’t have enough motivational forces to produce high-quality products. On the photo we see a soviet soap. It’s extremelyuninspired, has no packaging but a protective paper and the only information on it is: the percentage of oily substances. You can compare it to how an example of a modern soap looks, created under fierce competition. Soviet soap photo: Shutterstock with proper license Soviet shield: wikipedia Dove bar: dove.com under Fair Use terms. https://www.dove.com/us/en/washing-and-bathing/beauty-bar/white-beauty-bar.html
- Now, if you decide to treat your API portfolio as a free market, you need to make sure that you have two crucial forces that are required for proper functioning of real markets: advertising and natural sun-setting of products. Advertising, while it may be annoying when you are watching your favorite TV show, is very important for informing consumers. You will have to create an internal developer evangelism function to make sure you properly mimic it. Secondly, in free market bad products have natural way of dying – if nobody buys a product, it starves for resources and eventually disappears. In a corporation you can endlessly fund your APIs or tech products just by knowing and befriending the right people. So if you treat your APIs as products in a market, you need to make sure that the ones that do not get natural adoption will organically disappear, and won’t get funding. If you don’t facilitate these two forces, encouraging duplication may not be appropriate for you.
- Hopefully we have given you a lot examples to convince you that reuse can be dangerous. However you are probably still asking yourself: “but isn’t duplication costly?” Doesn’t reuse save money? Well, not necessarily. First of all, enforcing reuse for every single thing can be extremely costly itself, and not worth it. Secondly, we know from manufacturing theory that if we are trying to optimize overall cost of a complex process, local cost is a bad optimizer. Only overall throughput matters. And lastly, reuse creates tight dependencies on different parts of your system. And those dependencies may create cost-saving initially, but over time their cost goes up exponentially. The cost of dependencies may eventually surpass any savings in reuse.
- Next thing you may be worrying about is: security of letting just anybody implement crucial services. But in reality that’s not the case. Just having a free market of services doesn’t mean that every service comes from free market. Just like in real world, most of our products are market products but we also have government services and public goods that are subsidized. Every community makes their own decisions about what should be centralized and what should be in free market. Likewise, you have a lot of control in your organization to adjust these levers, but by default most of the services should be in “free market”, if you are doing it right.
- Microservice architecture is the implementation of your system, it is not the public API interface of your system that external or most internal clients should depend directly on.
- We can visualize the relationship between public APIs and microservices with this conceputal diagram. Please excuse my drawing skills, I am obviously horrible at it :) It’s interesting that this kind of separation was used by various companies even before the term “microservices” was coined. Daniel Jacobson called it “ephemeral APIs” in 2013, to emphasize the changing nature of those APIs, focused on implementation rather than durable interface. In contrast, APIs that constitute public interface of the systems were called “experience APIs” at Netflix. Soundcloud, another early adopter of Microservices coined a different term to highlight this separation, there the experience APIs were called Backends for Frontends. <CLICK>
- In conclusion, we believe that reuse is neither inherently good or bad. It shouldn’t be a commandment of software engineering, but it should also not be outright rejected in all cases. The question of reuse or not is a very nuanced one and we should approach it with a careful consideration rather than a zealous pursuit. Thank you very much!