Architectures You Ve Always Wondered About EMag

Download Architectures You Ve Always Wondered About EMag

Post on 10-Jan-2016

4 views

Category:

Documents

0 download

Embed Size (px)

DESCRIPTION

From InfoQ

TRANSCRIPT

<ul><li><p>Architectures you Always Wondered About // eMag Issue 31 - Aug 2015 1</p><p>eMag Issue 31 - August 2015</p><p>PRESENTATION SUMMARY</p><p>Service Architectures at Scale</p><p>INTERVIEW</p><p>Eric Evans on DDD at 10</p><p>ARTICLE Microservice trade-offs</p><p>FACILITATING THE SPREAD OF KNOWLEDGE AND INNOVATION IN PROFESSIONAL SOFTWARE DEVELOPMENT</p><p>Architectures you Always Wondered About</p><p>Lessons learnt from adopting Microservices at eBay, Google, Gilt, Hailo and nearForm</p></li><li><p>FOLLOW US CONTACT US</p><p>Martin Fowler on Microservice trade-offsMany development teams have found the microservices architectural style to be a superior approach to a monolithic architecture. But other teams have found them to be a productivity-sapping bur-den. Like any architectural style, micros-ervices bring costs and benefits. To make a sensible choice you have to understand these and apply them to your specific context.</p><p>Eric Evans on the interplay of Domain-Driven Design, microservices, event-sourcing, and CQRSThe interview covers an introduction to DDD, how the communitys under-standing of DDD has changed in the last 10 years, strategic design, how to use DDD to design microservices, and the connection between microservices and the DDD bounded context.</p><p>Lessons Learned Adopting Microservices at Gilt, Hailo and nearFormThis article contains an extensive interview on the mi-croservices adoption process, the technologies used, the benefits and difficulties of implementing microservices, with representatives from Gilt, Hailo and nearForm.</p><p>Building a Modern Microservices Architecture at Gilt</p><p>After living with microservices for three years, Gilt can see advan-tages in team ownership, boundaries defined by APIs, and complex problems broken down into small ones, Yoni Goldberg explained in a presentation at the QCon London 2015 conference. Challenges still exist in tooling, integration environments, and monitoring.</p><p>Evolutionary ArchitectureRandy Shoup talks about designing and building micros-ervices based on his experience of working at large compa-nies, such as Google and eBay. Topics covered include the real impact of Conways law, how to decide when to move to a microservice-based architecture, organizing team structure around microservices, and where to focus on the standardization of technology and process.</p><p>Service Architectures at Scale: Lessons from Google and eBayRandy Shoup discusses modern service architectures at scale, using specif-ic examples from both Google and eBay. He covers some interesting lessons learned in building and operating these sites. He concludes with a number of experience-based recommendations for other smaller organizations evolving to -- and sustaining -- an effective service ecosystem.</p><p>GENERAL FEEDBACK feedback@infoq.com</p><p>ADVERTISING sales@infoq.com</p><p>EDITORIAL editors@infoq.comfacebook.com</p><p>/InfoQ@InfoQ google.com</p><p>/+InfoQlinkedin.com</p><p>company/infoq</p></li><li><p>Architectures you Always Wondered About // eMag Issue 31 - Aug 20154</p><p>A LETTER FROM THE EDITOR</p><p>This eMag has had an unusual history. When we started to plan it the intent had been to look at the different architectural styles of a number of the well known Silicon Valley firms. As we start-ed to work on it though it become apparent that nearly all of them had, at some level, converged towards the same architectural style - one based on microservices, with DevOps and some sort of agile (in the broadest sense) management ap-proach. </p><p>According to ThoughtWorks Chief Scientist Martin Fowler the term microservice was dis-cussed at a workshop of software architects near Venice in May 2011, to describe what the partic-ipants saw as a common architectural style that many of them had begun exploring recently. In May 2012, the same group decided on microser-vices as the most appropriate name. </p><p>When we first started talking about the mi-croservices architectural style at InfoQ in 2013, I think many of us assumed that its inherent oper-ational complexity would prevent the approach being widely adopted particularly quickly. Yet a mere three years on from the term being coined it has become one of the most commonly cited approaches for solving large-scale horizontal scaling problems, and most large web sites in-cluding Amazon and eBay have evolved from a </p><p>monolithic architecture to a microservices one. Moreover the style has spread far beyond its Bay Area roots, seeing widespread adoption in many organisations.</p><p>In this eMag we take a look at the state of the art in both theory and practice.</p><p>Martin Fowler provides a clear and concise summary of the trade-offs involved when choos-ing to work with the style.</p><p>Eric Evans talks about the interplay of Do-main-Driven Design, microservices, event-sourc-ing, and CQRS.</p><p>Randy Shoup describes experiences of working with microservices from his time at eBay and Google. He focuses on the common evolu-tionary path from monoliths to microservices and paints a picture of a mature services envi-ronment at Google. In a follow-up interview he elaborates on some of the lessons from this ex-perience.</p><p>Then Abel Avram speaks to three com-panies - Gilt, Hailo and nearForm - about their experiences covering both building a microser-vices platform from scratch and re-architecting a monolithic platform by gradually introducing mi-croservices. In the follow-up presentation sum-mary we take a more detailed look at Gilt.</p><p>took over as head of the editorial team at InfoQ.com in March 2014, </p><p>guiding content creation including news, articles, books, video presentations, and interviews. Prior to taking on the full-time role at InfoQ, Charles led InfoQs Java coverage, and was CTO for PRPi Consulting, a remuneration research rm that was acquired by PwC in July 2012. For PRPi, he had overall responsibility for the development of all the custom software used within the company. He has worked in enterprise software for around 20 years as a developer, architect, and development manager.</p><p>CHARLES HUMBLE</p></li><li><p>Architectures you Always Wondered About // eMag Issue 31 - Aug 2015 5</p><p>Microservice trade-offs by Martin Fowler</p><p>Read on martinfowler.com</p><p>Many development teams have found the microservices architectural style to be a superior approach to a monolithic architecture. But other teams have found them to be a productivity-sapping burden. Like any architectural style, microservices bring costs and benefits. To make a sensible choice you have to understand these and apply them to your specific context.</p><p>Martin Fowler is an author, speaker, and general loud-mouth on software development. Hes long been puzzled by the problem of how to componentize software systems, having heard more vague claims than hes happy with. He hopes that microservices will live up to the early promise its advocates have found.</p><p>Strong Module Boundaries: Microservices reinforce mod-ular structure, which is par-ticularly important for larger teams.</p><p>Microservices provide benefits</p><p>Independent Deployment: Simple services are easier to deploy, and since they are autonomous, are less like-ly to cause system failures when they go wrong.</p><p>Technology Diversity: With micro-services you can mix multiple lan-guages, development frameworks and data-storage technologies.</p></li><li><p>Architectures you Always Wondered About // eMag Issue 31 - Aug 20156</p><p>Distribution: Distributed sys-tems are harder to program, since remote calls are slow and are always at risk of fail-ure.</p><p>but come with costs</p><p>Eventual Consistency: Maintain-ing strong consistency is extremely difficult for a distributed system, which means everyone has to man-age eventual consistency.</p><p>Operational Complexity: You need a mature operations team to manage lots of services, which are being redeployed regularly.</p><p>Strong Module BoundariesThe first big benefit of microser-vices is strong module boundar-ies. This is an important benefit yet a strange one, because there is no reason, in theory, why a mi-croservices should have stron-ger module boundaries than a monolith.</p><p>So what do I mean by a strong module boundary? I think most people would agree that its good to divide up software into modules: chunks of software that are decoupled from each other. You want your modules to work so that if I need to change part of a system, most of the time I only need to understand a small part of that system to make the change, and I can find that small part pretty easily. Good modular structure is useful in any pro-gram, but becomes exponential-ly more important as the soft-ware grows in size. Perhaps more importantly, it grows more in im-portance as the team developing it grows in size.</p><p>Advocates of microservices are quick to introduce Conways Law, the notion that the struc-ture of a software system mirrors the communication structure of the organization that built it. With larger teams, particularly if these teams are based in differ-ent locations, its important to structure the software to recog-nize that inter-team communi-cations will be less frequent and more formal than those within a team. Microservices allow each team to look after relatively inde-</p><p>pendent units with that kind of communication pattern.</p><p>As I said earlier, theres no reason why a monolithic system shouldnt have a good modular structure. [1] But many people have observed that it seems rare, hence theBig Ball of Mudis most common architectural pattern. Indeed this frustration with the common fate of monoliths is whats driven several teams to microservices. The decoupling with modules works because the module boundaries are a barrier to references between modules. The trouble is that, with a mono-lithic system, its usually pretty easy to sneak around the barrier. Doing this can be a useful tacti-cal shortcut to getting features built quickly, but done widely they undermine the modular structure and trash the teams productivity. Putting the mod-ules into separate services makes the boundaries firmer, making it much harder to find these can-cerous workarounds.</p><p>An important aspect of this coupling is persistent data. One of the key characteristics of mi-croservices isDecentralized Data Management, which says that each service manages its own database and any other service must go through the services API to get at it. This eliminatesIn-tegration Databases, which are a major source of nasty coupling in larger systems.</p><p>Its important to stress that its perfectly possible to have firm module boundaries with a monolith, but it requires disci-</p><p>pline. Similarly you can get a Big Ball of Microservice Mud, but it requires more effort to do the wrong thing. The way I look at, using microservices increases the probability that youll get better modularity. If youre confident in your teams discipline, then that probably eliminates that advan-tage, but as a team grows it gets progressively harder to keep dis-ciplined, just as it becomes more important to maintain module boundaries.</p><p>This advantage becomes a handicap if you dont get your boundaries right. This is one of the two main reasons for aMono-lith First strategy, and why even those more inclined to run with microservices early stress that you can only do so with a well understood domain.</p><p>But Im not done with ca-veats on this point yet. You can only really tell how well a system has maintained modularity after time has passed. So we can only really assess whether microser-vices lead to better modularity once we see microservice sys-tems that have been around for at least a few years. Furthermore, early adopters tend to be more talented, so theres a further delay before we can assess the modularity advantages of micro-service systems written by aver-age teams. Even then, we have to accept that average teams write average software, so rather than compare the results to top teams we have to compare the result-ing software to what it would have been under a monolithic </p></li><li><p>Architectures you Always Wondered About // eMag Issue 31 - Aug 2015 7</p><p>architecture - which is a tricky counter-factual to assess.</p><p>All I can go on for the mo-ment is the early evidence I have hear from people I know who have been using this style. Their judgement is that it is significant-ly easier to maintain their mod-ules.</p><p>One case study was partic-ularly interesting. The team had made the wrong choice, using microservices on a system that wasnt complex enough to cov-er theMicroservice Premium. The project got in trouble and needed to be rescued, so lots more people were thrown onto the project. At this point the mi-croservice architecture became helpful, because the system was able to absorb the rapid influx of developers and the team was able to leverage the larger team numbers much more easily than is typical with a monolith. As a result the project accelerated to a productivity greater than would have been expected with a monolith, enabling the team to catch up. The result was still a net negative, in that the soft-ware cost more staff-hours than it would have done if they had gone with a monolith, but the microservices architecture did support ramp up.</p><p>DistributionSo microservices use a distribut-ed system to improve modulari-ty. But distributed software has a major disadvantage, the fact that its distributed. As soon as you play the distribution card, you incur a whole host of complex-ities. I dont think the microser-vice community is as naive about these costs as the distributed objects movement was, but the complexities still remain.</p><p>The first of these is perfor-mance. You have to be in a really unusual spot to see in-process function calls turn into a perfor-mance hot spot these days, but </p><p>remote calls are slow. If your ser-vice calls half-a-dozen remote services, each which calls anoth-er half-a-dozen remote services, these response times add up to some horrible latency character-istics.</p><p>Of course you can do a great deal to mitigate this prob-lem. Firstly you can increase the granularity of your calls, so you make fewer of them. This compli-cates your programming model, you now have to think of how to batch up your inter-service inter-actions. It will also only get you so far, as you are going to have to call each collaborating service at least once.</p><p>The second mitigation is to use asynchrony. If make six asyn-chronous calls in parallel youre now only as slow as the slowest call instead of the sum of their la-tencies. This can be a big perfor-mance gain, but comes at anoth-er cognitive cost. Asynchronous programming is hard: hard to get right, and much harder to debug. But most microservice stories Ive heard need asynchrony in order to get acceptable performance.</p><p>Right after speed is reliabil-ity. You expect in-process func-tion calls to work, but a remote call can fail at any time. With lots of microservices, theres even more potential failure points. Wise developers know this and design for failure. Happily the kinds of tactics you need for asynchronous collaboration also fit well with handling failure and the result can improve resiliency. Thats not much compensation however, you still have the extra complexity of figuring out the consequences of failure for every rem...</p></li></ul>

Recommended

View more >