SOA: hoe in te voeren? (2)

Rik schrijft:
"ESB gedreven SOA". Bestaat er dan ook zoiets als "niet ESB gedreven SOA"? Volgens mij niet. Zelfs in een volledig geharmoniseerde en gestandardiseerde wereld zul je altijd berichten moeten routeren, gegarandeerd moeten transporteren en moeten orkesteren. Of zie jij een alternatief?

Ja, ik zie wel een alternatief.

Natuurlijk, dat routeren, transporteren, enzovoort is nodig. Maar is het nodig dat allemaal te integreren in één tool, namelijk de ESB? Die is duur om aan te schaffen, duur om te implementeren, en bovendien proprietary, wat in feite betekent dat het bedrijf in kwestie zich min of meer uitlevert aan de vendor.

Bovendien zijn heel veel van die "luxe" functionaliteiten van een ESB helemaal niet zo hard nodig, en worden ze zelden gebruikt.

Door dit alles worden die ESB-implementaties noodzakelijkerwijs company-brede projecten, en zoals we allemaal weten: die mislukken, zeker als ze niet 100% nodig zijn. En dat zijn die ESB-projecten niet, omdat er altijd een plan B is: een beetje halfwas invoeren, en de rest naar de toekomst schuiven. En plan C is: installeren, roepen dat je het gebruikt, maar in werkelijkheid gewoon de ouwe trouwe messagebroker blijven gebruiken.

Ik zie zeker twee alternatieven.
1. gebruik een mean&lean "ESB" voor de routering etc van het berichtenverkeer, en gebruik daarvan de functionaliteit op een dusdanige wijze dat je kunt switchen naar een ander tool. Een manier om dat te doen, is het gebruik van meer dan één ESB, maar dat stuit uiteraard nog wel eens op investeringsgrenzen.
2. gebruik een REST-route, en ga naar een ROA-architectuur. Dat kan ook, daar is nauwelijks extra tooling voor nodig, en kan incrementeel worden gedaan. Maar het sluit (in ieder geval op het eerste gezicht) veel minder goed aan bij de bestaande architectuur, en bovendien weten systeemarchitecten e.d. nit hoe ze dit moeten aanpakken.

Een extra argument voor deze alternatieve routes is dat de ver-SaaS-ing of ver-cloud-ing van de functionaliteit eraan komt, en dan zit een zware proprietary ESB ontzettend in de weg, zowel technisch als budgettair.

Niet doen dus, het zijn dinosaurussen.

SOA: hoe in te voeren?

Jonathan Mack op InfoQ, over hoe moeilijk het is om SOA in te voeren.


"When it comes to the SOA roadmap, the two most popular approaches to SOA implementation have emerged lately:

• Enterprise (top-down) SOA approach, which is an extremely high - risk approach with an initial price tag of a several million dollars. In addition, based on the size and complexity, such project can virtually never be accurately estimated.
• Grassroots (bottom-up) SOA approach - implementing elements of SOA (both services and infrastructure) as parts of existing business-driven IT undertaking. This approach typically does not succeed. On one hand, the scope of resulting services is limited to the specific business problem and might not be applicable (or even wrong) for the rest of enterprise. On another hand, the time and expense required to build the SOA layer can detract from other business needs of a project."

OK, dat lukt dus niet. Mack gaat dan verder met constateren dat een incrementele aanpak beter is:
"...to build SOA incrementally. Most vendors have come around to recognizing that this is the most reasonable approach. Nevertheless, it’s not simple to accomplish. The key elements of an Enterprise Server Bus (ESB) - the ability to translate and transform information from one system to another and the ability to route messages - as well as the messaging infrastructure to transmit the information must be in place from the beginning. Common (shared) services such as logging, monitoring, and exception handling also should be Day 1 implementations."




Ja, zo ken ik er ook nog wel een paar. Dit is dus ook een moeizaam verhaal.

Conclusie: SOA, althans ESB gedreven SOA, werkt niet.

Misschien wat kort door de bocht, maar eigenlijk komt het daar wel op neer. Zie ook dit en dit.

O'Reilly gelooft ook niet in het advertentie-model

Ik loop nu al enige tijd te schoppen tegen het advertentiemodel als dè inkomstenbron voor het Web te schoppen. En O'Reilly vindt dat ook.

Content delivery door Amazon AWS

Kijk, dit zat er in: content delevery via één API door AWS. Koppeling met het betaalsysteem FPS ligt natuurlijk vreselijk voor de hand.

Zie AWS blog en Werner Vogels.

Google op zee

Google wil datacenters op zee. Om de golfenergie te gebruiken. En om minder belastingen te betalen. En misschien ook wel om minder last van wetten en regels en juridisch gezeur te hebben.

Onzin over cloud computing

De laatste tijd lees ik nogal eens van die verhalen waarin wordt gezegd da cloud computing er niet is of komt, omdat er nog steeds on-premise computing is en blijft. Staat op mijn lijstje om eens op te reageren, maar Anshu Sharma heeft het al gedaan. Hij heeft groot gelijk.

SaaS lock-in: een risico?

Vendor lock-in bij SaaS-oplossingen wordt de laatste tijd nogal eens als risico van SaaS geschetst. Terecht, want lock-in is altijd een probleem, bij een pakket, bij SaaS, en ook bij zelfgebouwde oplossingen.

Maar het lock-in risico bij SaaS wordt overdreven. Wel gelden vier regels:

1. Kies alleen SaaS-oplossingen waarbij je ondubbelzinnig eigenaar van de data bent en blijft.

2. Zorg voor een model (bijvoorbeeld een objectmodel) waarin de business beschreven is, en projecteer dat op het model van de leverancier. Dit is nodig voor conversies, voor koppelingen en voor de exit-strategie.

3. Kies alleen SaaS-oplossingen met goede interfaces. Niet alleen user-interfaces, maar ook APIs voor data-verkeer en integratie.

4. Gebruik die APIs vervolgens zo min mogelijk. De kracht van SaaS zit vooral in de lage kosten en investeringen. Gooi dat voordeel niet weg door niet echt noodzakelijke integratie zelf te bouwen, want daarmee lockt u uzelf in.

Kortom: lock-in is een beheersbaar risico. En de Pavlov-reactie van IT-ers om dan maar zelf iets te gaan bouwen, maakt het erger. Misschien wordt de vendor lock-in iets minder, maar de maatwerk lock-in wordt des te groter.

Cloud browser

Google heeft Chrome uitgebracht, in beta. Chrome is een webbrowser, op het eerste gezicht een concurrent van Firefox, IE, Safari, Opera, etc. Maar er is een verschil: Chrome is vooral gericht op het ondersteunen van het runnen van webapplicaties.

En ik denk dat het Google niet zozeer gaat om het van de markt drukken van IE of zo, maar om het versnellen van het gebruik van webapps.