Skip to main content


Showing posts from 2019

My2Cents - Eight things leads to developing catastrophic cloud native microservices system

More of my two cents, just my thoughts. A quick fun read, not too deep, but worth noting :). 1. Setting the domain boundary wrong This is a job guarantee tactics, it's endless looping in development and testing for everyone involved in the project without making the service to production! First everything starts simple and gradually find more and more functions, business logic gets added into the microservice, at the end, one even have to rename the whole damn thing.  Symptoms and side effects  A growing microservices becomes too fat, or every single microservices in the domain calls your microservice. (Sometime core microservice has the same behavior, but you should not see many of this type of services in a single domain.) This violates the microservices principle of easy, maintainable and agile. Duplication of microservices/code everywhere. Where you find bits and pieces of duplicate code or microservices being copied and deployed into other domains.  If you get

AMQ Online 101 - What I've learnt from recent AMQ Online Hackfest

AMQ Online, project name, EnMasse. Recently, I've attended AMQ Online Hackfest where the Rob and Ulf the engineering team kindly ask us to take a hack on the new platform. If you don't know what AMQ Online is, it's basically an online self-service (Messaging as a Service) messaging platform for developers/application owners to quickly spin up their own queue and topic without worrying about the scalability, network setting and all sorts of operation setups. Watch this quick video overview on what is AMQ Online: Before the hack, they went through the basics of AMQ Online, and here is my take on explaining the basics of AMQ Online. With AMQ Online being the platform to service users, there are obviously two main area of focus for people depending on their roles.  The administration side to spin up and manage the platform, the other side of course is the user end, where they will be requesting for the message services. Admin does the installation of the platform fou

My 2cents on the future of Integration - With Service Mesh/Istio and Serverless/KNative

It's been a year and half since I blogged about "Agile Integration architecture" (Gosh, time just flies). With the "microservices" and "cloud-native" hype, I was especially curious on how all these new concept and technology affect us on how to architect the integration systems. If you ever pay close attention to all the latest and greatest news from the Kubernetes community, I am sure you will hear a lot about the new "Service Mesh". And rumor has it that this is how integration can/should be done in cloud native world, but, is that so? Anyone who has ever worked on an integration project would tell you, it's a LOT more COMPLEX and can get worst overtime. I did a talk with Christian Posta in Red Hat Tech Exchange coming from a more comprehensive view of how different Red Hat technologies are applied under different patterns when building integration solutions. In fact he also did a great blog about it. Since then, another topics has