Hi Paul,
There is nothing wrong with SOA, or to be inspired by the ideas, which are not that radical to programs calling programs pre web. The book you're reading, I read the early beta, some aspects I didn't concur, but thats the joy of this work. Where I've used it the real pain has always been around testing. Versioning of the endpoints is I'd say mandatory, coupled with the most fragile of assumptions, human nouse. Actually deploying it, designing it I find a little easier when separated to logical points. The pain on testing, naively take two apps, modify the service endpoints, rewrite tests and both would pass, but neither will work together. Tools out there such as vcr, et al will only work if the api contracts don't change. Writing / modifying contract tests then should trigger a thought in the developers mind, why am I changing this and what's the impact… you could point your CI to talk to a real staging set of services... Overall application/implementation complexity is increased, but individual applications are much easier to understand and of course can be taken out and replaced with <insert framework/language>. That alone could be a powerful asset. Snowflake applications benefit greatly as it's actually reducing code repeated between them. As Francis says it depends on the app/vision. --- Where I introduced the concepts, it had an impact, yes it cost dev time, yes it was questioned by many, including myself. The site we inherited consisted of two 'monolithic' applications a front (perl) and rear(rails). A new front end; in rails, was coming, along with a different data structure to the rear, different lookup ids, sequencers etc… coupled to that, touch one the other would invariably break in some unforeseen way. 1000+ line models, scant tests, pain written all over it and our faces. We introduced services and middleware, message queues to handle interfaces/contact points between the applications, e.g. passing an order into the backend. Another was a feature with several gig of effectively transient data in the core application, it impacted everything, db IO, backups, restore, performance etc… that was obvious to pull out and replace with service calls. In the extraction we could also identify the features; nobody truly knew, write tests and if that service/db failed, it didn't take the site down. It was far leaner so could actually be improved, about 99.9% improvement by time we'd finished on it. As an aside it also meant we could reduce our PCI exposure, so PCI only covered core apps, push the non core off to different servers/datacentres if need be. To summarise my thoughts on SOA… - Monolithic or single app is the rails way, SOA totally depends totally on your app. I suspect most apps written are actually fine and SOA is overkill. - Take a small non-core aspect and build out from there. - You app will be more stable all in one. - You can drive performance and agility faster on separated applications, more flexibility. - Get it wrong and it's your sea anchor, same goes for going to far. - Aim for <10ms response times, anything over 50ms investigate and tune (this is where cost comes in) - If behind nginx, memcache can be your best friend… http://wiki.nginx.org/HttpMemcachedModule use the api uri as the memcache key ;) Caveat: all data must be same type. - Refactoring has to be completed, a mistake I made was not getting enough to time to clean up, this left confusion and half open doors. - Do it or do not, but be aware it's going to take longer and that may leave the product owner scratching head... Apologies for length, off to read up on hexagonal, missed that somehow. Hope this helps in some way. Colin -- You received this message because you are subscribed to the Google Groups "NWRUG" group. To view this discussion on the web visit https://groups.google.com/d/msg/nwrug-members/-/a3mqw3M2YiAJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nwrug-members?hl=en.
