Through my day job at Capgemini UK I have regular dealings with Flexagon as we use their FlexDeploy product with a number of customers (as we do recommend the product). Recently I was invited to contribute to a paper being developed by the Flexagon team. The fruits of the collaboration are now available at https://info.flexagon.com/ebook/devops-for-developers. The Flexagon team have done a nice job with it, and we’d recommend taking a look if you’re wanting to know more about DevOps and CI/CD.
The paper is completely free of sales pitch – completely devoid of product references which makes for a good read.
Last week I was fortunate enough to attend RedHat’s day in London on Microservices. There were some great presentations and some ideas that are both simple and potentially very effective. It wasn’t a simple Microservices solves everything get into out tech stack, there was some reality checks as well.
The challenge I have been unable to square up yet, is the idea that each Microservices would have its own UI. On the surface, it makes a lot of sense, after all the UI needs to reflect the capabilities of the service.
The challenge comes in the form, that a User Interface needs to have consistency across the board. Yes, many will immediately point to CSS., which undeniably provide a level of consistency. But UI needs run a lot deeper. Let me point out a couple of illustrations of this:
- Recent switch to web interfaces reflecting the new ‘flat’ visual format
- Adoption of app on a page through AngularJS
- Lots of illustrations can be seen at elegant Theme
This goes beyond CSS3 in many cases, but the libraries being used – so impacting development. Now here is the rub, the backend service functionality won’t change but the UI implementation will and needs to be deployed consistently across the board in one go for B2B and critically for B2C. You can destroy a good product with a poor UI and sell a rubbish app with a good one. All of which would mean deploying updated all Microservices at once if they embody the UI. The linking of all the Microservices like this is completely contrary to the goals of agility driven the Microservices strategy.
Add to this, the Microservices approach promotes a DevOps approach, yet organisations may only employ 1 or 2 real user experience specialists rather than try and spread them across multiple service teams it maybe better to focus them into one or two service teams that just build the UI.
Which kind of leads me to the argument that I would suggest that your UI is a separate service or small group of services to the core functional side of things. So those PR driven website overhauls, and revisions to match user experience expectations can be done without impacting the core capabilities, demanding a total regression test and locking your entire set of services into a unified release cycle.