• stakes (5/2/2016)


    Eric M Russell (5/2/2016)


    However, the downside of this architectural approach is that I see a lot of queries written by the application developing teams that (in all fairness by necessity) use remote table joins (4 part naming convention), which kills performance. Even if the separate source servers are scaled up with more CPU/RAM, the performance for these distributed queries still sucks. There is often times no truely graceful solution other than the change the location of the database, which of course then creates other political and technical problems. Optimizing distributed queries is not the type of task I want to see routinely land in my Kanban queue.

    Is this a Microservices architecture?

    Honestly, I don't think it was ever "architected" this way at a high level; it just sort of happened in way similar to urban sprawl. If you ask the application developers, then maybe they'll call it a microservices architecture, and there may even be some misguided fool who will proudly take credit for it. However, from the Operational / BI / DBA point of view, distributing joins across instances is all evil and can do no good.

    I think maybe it's time to bulldoze most of the these sprawling VM enclaves and replace them with a handful of profressionally atchitected high rises.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho