A High-Performance Solution to Microservice UI Composition @ XConf Hamburg

Editor's Notes

• #2: THIS IS FOR HAMBURG ONLY
• #3: THIS IS FOR HAMBURG ONLY Besides being a developer at ThoughtWorks, Arif is a serious coffee geek Between (and while) drinking coffee he thinks about Microservices, writes preferably Scala code, and likes the challenge of generating insights out of large amounts of data
• #4: - This is Moritz’ official business card .. he’s calling himself a DevOps Birth Assistant, the male version of a midwife - That’s because he’s helping his customers deliver babies .. software babies, with all their quirks, differences, and joyful moments - and he does all this using the methodologies behind DevOps
• #5: This is a quote from the book “Small pieces loosely joined - a unified theory of the web” by David Weinberger, I’ll give you a moment to read it Essentially, it is describing us as human beings in an interconnected world, and there are very true parallels if you want to explain the concept behind UI composition, “Small pieces loosely joined” describes it pretty well The book is about the Internet, and how we use it, how we interact with it and through it, and the Internet as such is a composition! A couple of million servers, in a network, at worldwide scale, presenting content of an incredible large variety It is highly composed, while still performing at absolutely acceptable rates, with individual companies and teams in charge of the responsible layers But what’s happening if things aren’t so well connected, or worse, even centralized and monolithic?
• #6: We are able to present this today because one of our clients, AutoScout24, embarked on an ambitious mission almost 2 years ago They are still on it, and with a lot of success! They had the same problem as any larger organization: Large, monolithic applications, very hard to maintain, carrying a lot interest and business logic in one huge blob Inflexible and resistant to change Intersecting responsibilities across teams Architecture is dictated by requirements in existence aeons ago Delivering updates, bugfixes and new features is bound to a single, manual process The advantages though: It’s a single point of entry for consumers! Browsers don’t need to do anything special in order to use it For them the monolith is an easy, one-stop solution, because it carries all the logic and feeds it to browsers But, AutoScout24 wanted change
• #7: They wanted to be able to release faster, with teams working autonomously, carrying responsibilities towards business goals and values They chose to not only achieve these goals with a single set of changes, but four separate ones They are breaking apart their monolithic .NET application, moving towards Microservices They are abandoning their own two datacenters for the AWS cloud They are switching away from .NET and C# towards the JVM and Scala in particular And on top of it all they are going to run all of it on Linux Additionally: Continuous Delivery and DevOps Innovation and development in autonomous teams Reduce time to market of features and bugfixes Attract talent Read more about it in their extraordinary IT principles, published on GitHub If you want to start your own transformation it’s an excellent document to start with They also chose the pattern of UI composition for bundling their applications together But what is that exactly?
• #8: This is the Wikipedia definition of “Composition”, as you might realize it’s the description for “visual composition”, but it’s very much applicable to compositions of any sort It a way it’s like a symphony, an arrangements of many different strains of instruments in perfect harmony How do we map this to our software composition example, though?
• #9: If you want to shift that picture towards Microservices you can see a very easy pattern emerge At first you have a single Microservice, which can do stuff And then maybe there comes another one, and either of them can do stuff, and maybe they can do even more stuff when combined However, as you might have guessed, this space gets crowded pretty easily, especially when you have different business goals driving you forward And it gets even more complicated once each of the components has to talk to one another, has dependencies and expectations etc.
• #10: In a sense it’s like an orchestra: They all know the end result they’re supposed to provide, the symphony or in the case of Microservices, their business focus Any individual member of the orchestra might be excellent at what they are doing, and they are probably are going to be able to play beautiful music without any further help by just listening to one another or reading from the same sheet of music Like our Microservices could do But this gets more and more complicated the more interests (i.e. instruments) and intersecting responsibilities (i.e. different melodies) you are accumulating; they need somebody who is able to put it all together, make sense of the chaos. They need a conductor
• #11: THIS IS FOR HAMBURG ONLY If you haven’t recognized him from the first slide, this is Thomas Hengelbrock, he’s the current principal conductor of the NDR Elbphilharmonie Orchestra in Hamburg He is the single point within the orchestra that makes the symphony possible with a reasonable amount of coordination and understanding He doesn’t do much physically (waving a baton erratically, essentially), but he has the bigger picture in his head and is keeping track of the pace All the different parts of the orchestra are coming together, they are providing value (music), and the conductor just tells them if they’re on the right track or not And that’s what we need for our Microservices as well! We need a conductor ..
• #12: > Arif - Thank you, Moritz - Now let’s move to the actual UI Composition solution that we built at AutoScout and which we called Jigsaw - And of course, we called it Jigsaw because it helps us to cut the AutoScout page into smaller pieces which fit together perfectly
• #13: - At the same time, we do not want to compromise page performance by any means - We know that especially on mobile devices the responsiveness of a page dramatically determines how much users enjoy using the page - For measuring page performance, we rely mainly on Google’s PageSpeed Insights. Who knows what PageSpeed Insights is?
• #14: - Imagine this is the AutoScout homepage and it consists of several UI components such as - Now with the interpretation of Microservices that we implemented at AutoScout, each service delivers its own UI component, e.g., purple home page, later composed to a single web page - We often speak of vertical slices here, because there is no layered architecture anymore and each service can contain a backend, a UI, and everything in between - This way, each team can change their backend and their UI independently → Great for team autonomy - Now, to allow for real autonomy, services also need to deliver their own assets, such as stylesheets and JavaScript - However, if you naively combine this into one single page, the page performance will be terrible because you have CSS and JS scattered all over the page and render blocking content at various places
• #15: - You can then, for instance, try to make each service deliver their assets separately in order to optimize the page structures - For instance by grouping the CSS loading up here - And in fact, that was an approach that went for first - However, things get really messy now when caching comes into play - because a piece of HTML and a corresponding piece of CSS could be invalidated at different times so that you get version mismatches when releasing updates to the page
• #16: … of course there are alternatives to this UI composition approach, and a popular one is API Gateway Pattern combined with a Unified UI frontend
• #17: - However, there are some drawbacks of applying this pattern from which, for us, the most severe is that independent feature releases are no longer possible (as long as they contain UI changes) - Instead, in the worst case three teams are involved and need to be coordinated when changing a feature: the backend service team, the API gateway layer team, and the web app team - One could say that the API Gateway pattern one goes only half way to split the monolith, namely only in the backend - but because team autonomy is one of the main reasons we went for Microservices in the first place, this issue made the API Gateway pattern no option for us
• #18: Here’s a diagram of how Jigsaw, our UI composition conductor, works under the hood: Initially, there is always an entity requesting some resources, for our purposes that’s a browser requesting the content of a website to display to its consumer/user. Let’s say for this request the user wants to see the homepage of AutoScout24 The request, after navigating through Amazon’s CloudFront (not pictured) will hit our composer, Jigsaw, specifically its proxy module. Nginx, internally, knows which services it should serve under a certain Slash URL. For our homepage, which is a special case since it doesn’t usually care any prefix, that is /home. The re-routing is done by CloudFront. Nginx fires off a sub-request to the service registered within its proxy registry, in this case the application responsible for serving the homepage. The homepage app is returning a proper Index page, written in HTML, with a slight trick up its sleeve. It also includes so called Server Side Includes, instructing nginx to do further round-trips to gather other resources the Index needs in order to serve the request it has gotten initially for its Index. Nginx contains a module which is capable of resolving these resources we call fragments from other services via its proxy module, the SSI module. In the diagram the Index needs a fragments for the header and the footer, since those aren’t specific to the homepage, but rather for the whole web presence. There will be sub-sequent request to the service able to resolve the required fragments the other service formulated in its Index. In our case that’s the Contentservice, who’s able to resolve the HTML for the header fragment and the footer fragment It send these HTML fragments back to the SSI module, which is then putting it back together, to represent the Index of the service that was serving the original request, our homepage service. The resulting HTML is then passed on to the truly magical component in all of this: The ngx_pagespeed module. It’s a third party module developed by Google, to apply web development best practices to HTML code on the fly. With it we are able to satisfy the second important requirement we initially formulated: To be as fast as possible. Google, in this case, is our reference. Now, we couldn’t do all of this with every request, especially since about 95-99% of the content doesn’t really change all that frequently. That’s why both, the proxy module and the ngx_pagespeed module are able to cache content dynamically, based on URL keys, parameters, certain headers and content types. Javascript and CSS for example, is cached indefinitely, since all of it is strong cached, by the individual service but also by the ngx_pagespeed module. However, all the other cache handling is at the discretion of the individual services. If they want a certain part cached they will need to use the right Cache-Control headers. This enables all of them to use Jigsaw’s caching facilities autonomously, without any limitations or superimposed guidelines. 7. After ngx_pagespeed is done with its optimizations the results are served back to the browser, strong cached and optimized for the relevant browser at hand, without any specific optimizations having to be done by the individual services. Both, SSI and ngx_pagespeed are solving two very specific problems, and by combining them both we are unleashing their true power, enabling our teams to work without boundaries.
• #19: > Arif - So before showing an example how this actually looks in code - I have to explain that we conceptually distinguish between what we call a page and what we call a fragment - ...and does not know the original request - ...and this team is responsible for the performance and the stability of the page - So when this page includes fragments, this team has to define a contract with the providers of this fragment - The fragment on the other hand needs to obey this contract and behave well
• #20: Now let's look at a simple example page Page, therefore HTML tag+ head and body styles already minified by service SSI include syntax  
• #21: SSI resolved = include replaced with fragment (by Nginx) fragment has its own head, with its own minified styles in there also its own script section at its bottom very bad page speed as of now  
• #22: now comes mod pagespeed combine heads 
• #23: combine css combine js, defer its loading 
• #26: > Moritz Obviously, one of the challenges of coming up with this interconnected system, with distributed responsibilities was that the result, the product, still needed to provide the highest value to our customer, i.e. a page that worked We enabled all of our teams to test their composed services with a Jigsaw instance broad to your very machine using Docker and interchangeable services You can, if you want to, run a certain services somewhere else, in a separate environment, on your laptop, on your toaster (as long as it has web access), and emulate the Jigsaw behaviour through the right set of headers A test would use your version of Service A, but the production versions of Services B, C, D, etc. That way you have a high level of assurance when it comes to testing, and you’re more confident when composing your pages This is so easy, you can hand this out to your product management team and they would be able to test new revisions of your software, through Docker deployments, or even separate feature toggles, without any impact on production systems! All the facilities you usually have for testing a monolithic applications are still viable and very much possible
• #27: This way of composing web services provides a maximum amount of flexibility for otherwise highly dependent teams; none can work without the other, but they all can work together efficiently and effectively Due to the nature of the dynamic pipeline and the caching mechanism page owners have full control over how fast their pages are served to their customers, none of it is actively impairing performance All the best practices web developers usually have to dance around with we are entrusting to a source of truth (hint: Google) not only responsible for serving a large portion of the traffic websites receives these days, but also an entity who’s at the forefront of best practice web development. The phrase “if it works for Google it should work for us” is truly alive with this concept. This is Jigsaw, our UI composition conductor.