SOA Tech Magazine

During Oracle Code One 2018  (formerly Java One) I was lucky enough to deliver for the first time a funny yet insightful presentation titled " The Seven Deadly Sins of API Design " focused on API design anti-patterns and how to overcome them. I was also fortunate to have presented a similar session at Sangam 2018 in Bangalore and most recently at Devoxx UK 2019 in London. This presentation was partly inspired by Daniel Bryant  the 7 Deadly Sins of Microservices however with full focused on the topic of API design and API-led architectures, not so much on Microservices (though the too are so closely related that not talking about Microservices in some areas is impossible). But my main motivation was really around the fact that we're all sinners when it comes to making mistakes. When I first started designing REST APIs (or before that SOAP/WSDL based services), I myself made so many mistakes. However the main thing is to learn from them. And not just from our own mist...

I've come across the so called "Spotify model" several times. Pretty much every organisation I am working with is using it one way or another either as inspiration for their target organisation or as an example of what they would like their IT culture to be like. Thanks to the brilliant 2-part video posted by  Henrik Kniberg , I was able to listen, visualise and truly digest what this engineering culture actually means from a organisational, technological and people/culture point of view. To this end, I've created the following presentation with the intention to also share my interpretation of their engineering approach. Spotify engineering culture summary from luisw19 The Spotify engineering culture empowers its people at many different levels as it provides a very good balance of freedom and structure. It’s open approach towards collaboration, respect and trust, ensures that Squads are align, share knowledge and experiences, thus avoiding common pit...

API Gateways  deliver critical runtime capabilities in enterprise-wide API management infrastructures. However, such runtime capabilities must also be complemented with other design-time and governance capabilities in support of activities such as APIs lifecycle management, API design, policy definition and implementation, deployment, retirement, monitoring, and so on. The aforementioned design-time/governance capabilities, are often offered by different API management vendors as a separate M anagement Service infrastructure   that augments/complements the runtime infrastructure (API Gateways). Needless to say in order for runtime and design-time/governance infrastructure to work together cohesively as a collective whole, there must be some sort of effective and reliable communication between these two main components. Whereas some products like for example the  Oracle API Platform Cloud Service , deliver a phone-home approach for API Gateways to communicate with the...

With the massive uptake of Microservices Architecture -industry wide- and with it, the adoption of patterns such as Event Sourcing , CQRS and  Saga as the means for Microservices to asynchronously communicate with each and effectively " choreograph " business processes, it might seem as if the days of process orchestration using BPM engines (e.g.  Oracle Process Cloud  now also part of Oracle Integration Cloud , Pega, Appian, etc) or  BPEL (or BPEL-like) engines are over. Although the use of choreography and associated patterns (such as the aforementioned) makes tons of sense in many use cases, I've come across a number of them where choreography can be impractical. Some examples: Data needs to be collected and aggregated from multiple services -e.g. check the Microservice.io Composition pattern . Note that this pattern doesn't necessarily implies that an orchestration is required. Could be that data is collected and aggregated (not transformed) into a...

Earlier in the year, June to be exact, I published the OTN article  3rd-Generation API Management: From Proxies to Micro-Gateways  -based on a concept I presented in an Oracle OpenWorld 2016 Presentation titled  API management in the year 2026 . In summary, the article talks about how in the digital era requirements have changed when it comes to getting access to information. Fact that modern applications demand information in real time and expect it to be available 24x7, and also the side effect of cloud adoption which is causing information to become more and more federated amongst multiple cloud applications (from different vendors) and on-premises systems -as they won't go away that easily. The article continues by explaining that although  REST APIs play a critical role in providing such critical access, the underlaying technology stack that have traditionally enabled SOA architectures, typically based on monolithic middleware, will struggle to satisfy...

I've just literally arrived from Oracle Open World and JavaOne 2017 and my head still hurts with so many interesting announcements and cool new things I want to get my hands on and learn. This blogpost provides a short summary of my impressions and key takeaways from both events. General overview: This year OOW and JavaOne was full of changes from previous ones. For starting most of the sessions took place between Moscone South, Moscone West and the Marriot Marquis, as opposed to all over the place. I understand that this was mainly due to renovations that took place in Moscone which meant that more rooms were available. JavaOne this year took place in Moscone West (as opposed to Hilton Union Square). First thing that really stroke me was the vast amount of people that seemed to have attended the event (see below tweet from Adam Bien ). Not sure if more people attended JavaOne than OOW, but my first observation is that sessions in JavaOne were better attended than those in OO...

Oracle has recently announced the release of Oracle API Platform Cloud Service . Here the official press release . This new platform -not to be confused with Oracle's previous solution, has been built almost entirely from the ground up to satisfy modern API management requirements. I have been lucky enough to be part of the beta programme and have actually been implementing the product for the last 4 months or so (but trying it for almost a year now). In this blog post I share some of the insight and experiences I've gained in the process. What is the Oracle API Platform Cloud Service? Is a 3rd generation API Platform  that delivers a 'true hybrid' model that allows for APIs to be created, deployed and managed centrally (from the Oracle Cloud) whilst API gateways (engines that run the APIs) can be deployed in any cloud (i.e. Amazon, Azure, Oracle Cloud, IBM Softlayer/bluemix, etc) and/or on-premises. In addition with the incorporation of Apiary into the port...