Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
<CLICK>
1
Let	me	tell	you	a	little	bit	about	myself.	I	work	at	Capital	One,	where	I	lead	
microservices	transformation	efforts.	Micr...
You	see,	reusing	code,	reusing	APIs	has	traditionally	been	viewed	as	the	road	to	
efficiency	However,	a	lot	of	microservic...
Let’s	start	by	discussing	some	design	principles.	How	many	of	you	have	been	confused	
by	whether	you	should	push	or	pull	a...
A	proper	”push”	door	should	have	flat	surface	or	a	pushbar,	making	it	clear	that	the	
ONLY	thing	you	can	do	with	such	door...
Now,	it’s	too	easy	to	assume	that	the	designers	of	Norman	Doors	are	just	stupid.	In	
reality	it	is	not	always	the	case.	Th...
When	you	make	reuse	the	ultimate	goal,	you	will	end-up	designing	for	an	average	user	
and	end-up	creating	lowest	common	de...
Sometimes	designers	call	the	averaged	persona	a	“normal	user”	to	make	it	sound	
better,	but	designing	for	such	“normal”	us...
Remember	Maya	Angelou’s	words:	"If	you’re	always	trying	to	be	normal,	you	will	never	
know	how	amazing	you	can	be."
9
Aside	from	problems	with	averaging,	another	issue	is	that	reuse	can	kill	innovation.	If	
you	always	only	have	one	choice	–...
Now,	if	you	decide	to	treat	your	API	portfolio	as	a	free	market,	you	need	to	make	sure	
that	you	have	two	crucial	forces	t...
Hopefully	we	have	given	you	a	lot	examples	to	convince	you	that	reuse	can	be	
dangerous.	However	you	are	probably	still	as...
Next	thing	you	may	be	worrying	about	is:	security	of	letting	just	anybody	implement	
crucial	services.	But	in	reality	that...
14
15
In	conclusion,	we	believe	that	reuse	is	neither	inherently	good	or	bad.	It	shouldn’t	be	a	
commandment	of	software	enginee...
<CLICK>
17
Upcoming SlideShare
Loading in …5
×

Reuse or Not and Microservices

1,292 views

Published on

The Fallacy of Assuming Reuse Equals Efficiency and the challenge microservices practitioners have given to the DRY principle.

Published in: Data & Analytics
  • Be the first to comment

  • Be the first to like this

Reuse or Not and Microservices

  1. 1. <CLICK> 1
  2. 2. 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 last year 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. 2
  3. 3. 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. 3
  4. 4. 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. 4
  5. 5. 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. 5
  6. 6. 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 6
  7. 7. When you make reuse the ultimate goal, you will end-up designing for an average user and end-up creating lowest common denominator solutions. 7
  8. 8. 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. 8
  9. 9. Remember Maya Angelou’s words: "If you’re always trying to be normal, you will never know how amazing you can be." 9
  10. 10. 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 10
  11. 11. 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. 11
  12. 12. 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. 12
  13. 13. 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. 13
  14. 14. 14
  15. 15. 15
  16. 16. 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! 16
  17. 17. <CLICK> 17

×