Website embracing Microservices learning — Can it work at all?
I have been reading lot about Microservices and been part of a few development activities and have been a heavy consumer of these services to build high performance website. Benefits of Microservices are clear to us. Case studies of Netflix, Spotify and more and more were truly motivating.
I started recently on re-architecture of a retail company. Move is to refresh the site architecture from technology stalk perspective and how technology can improve current UX and address some of the glitches on current code base to allow faster time to market — being more agile.
Overall we felt good about moving ReactJS and going Universal made sense for us to render page on server side. So skipping that part, our one of our secret mission was to able to apply Microservices pattern to website.
What it meant to us?!
This website is pretty much like most of the e-commerce mobile website. Broadly there is a path-to-product and a path-to-purchase. In other workds, there are marketing home page, page listing categories or products, product details page and checkout flow.
At present, website was deployed as 2 application — browse and checkout. This allowed us reduce our regression impacts on our 2 important user experience flow. Teams are structured around this and there are workflows to manage our changes.
Having understood the benefit and overhead on splitting the team and website as 2 broad flows, we thought to explore our options to go beyond that. Can each page be considered silo website? Or in other word, can microservices concepts and benefits be extended to restructure current website.
(All below was on paper only with couple of POC running around, when I was writing this. So please read them with mercy :) )
Goal was ability to structure team and responsibility, isolate changes and build, test and deploy them without affecting other part of the website. In other words, let us pretend that different isolated POD team who don’t know each other are building the different part of the website.
First step was look at the website as discrete components. That made it is possible to visualize the application as pieces we could deploy. A page could be broken as reusable components (so called atoms, molecules, etc), each page being a container component and runtime (express + react code — website as shell as a container — comprising templates, common styling framework, routing, etc…)
First started with repository structuring to reflect this componentization. Repository was broken to component, page modules and App (so called runtime). ‘App container’ part delivers the consistent user experience, ‘page container’ delivers user engagement and ‘component’ delivers reusability.
Each App container may host more than one ‘page container’ and they run in their own docker container and routing takes care of the URL to container delivery. We are assuming, Zuul would take care of that and leaving the details out.
Remember each page is still a component that can support various templates you could think of. It is self-contained feature rich NPM package in our private repo. It is standalone and can be tested individually. It is pretty much like any component you may find in the wild.
As a team, say ‘HomePage team’, could start with the ‘App’ starter kit which comes with standard bundle — build step would spits out a website docker container out. But this ‘App’ itself does not have any feature to user. Those are delivered by respective ‘page container component’. Since page being component, you could always refer them as npm package dependency by locking yourself to a version. They are packaged and deployed like microservices.
Different part of your website runs are cluster of dockers!!
Of course, web is not similar to microservices and other common elements. Everyday’s brainstorming had something new coming up. But just a beginning. There are other complications however and feel free to comment and eager hear out thoughts