I have been working my way through Building Evolutionary Architectures by Neal Forward, Rebecca Parsons and Patrick Kua. Three senior and respected members of Thoughtworks (also the home of Martin Fowler). Having read and listened to Neal and Rebecca’s presentations and writing I had expected a deeply thought provoking read, but have to admit to being disappointed. There are some good points without a doubt, but the book pretty much focuses on one idea, the application of fitness functions. But I’m not convinced it warrants several hundred pages of a book as result the point does at times feel laboured.
There are some arguments made, that leave me thinking that there is a view that the only answer is microservices in the conventional model of Kubernetes, Docker etc, which I agree is a powerful paradigm to allow solutions to evolve, but it isn’t a silver bullet and not always right in every case (if you have a team lacking the underlying appreciation of the goals, or put in to place in an ad-hoc manner (see Chris Richardson‘s work) it isn’t going to help.
Alongside this, there is little said about the interface definition for microservices (typically APIs of one form or another). Whilst mention of leaky abstractions is made, the material illustrations such as code lead API definitions are omitted (risk being, code changes, the API changes and the impact cascades).
What surprised me the most is the on more than one occasion the books points to ERPs not being sufficiently customisable. Yet, anyone working with ERPs will tell you that ERPs are at their best when you use them to leverage industry best practices rather than crow bar them to fit unconventional ways of operating. If you’re a manufacturer, is fiscal reporting part of your differentiator; probably not, so why not take best practice OOTB.
As usual I have mind mapped things as I read through the book. The dynamic/interactive version is here, the image (but not in full detail) is below.
In January we presented our 1st online training, looking at API Design and use of Apiary and Swagger. Things went well until near the end where for some reason voice and video dropped for no apparent reason. Our coordinator Lindsay kept the recording going and soon as we reconnected I continued the session and went through the Q&A.
So if you missed the end of the end of the training, please do check back with the recording.
If you missed the training – we’ll be rerunning in March – go here.
For those on the training will have seen at the start of the training links to my social media profile, so happy to try respond to any further questions.
We are also scheduled to run the session again in a month or so.
One of the questions received during the session I thought worth mentioning was when would Apiary support Open API 3.0. Well according to their blog very soon, looking forward to it as the OAS 3 does look a little cleaner.
A while back I made some utilities I developed to help with managing the API Platform. At the time we didn’t have access to an IDCS based environment, so credentials worked using basic auth (I.e. user name and password). But with environments managed by IDCS tokens are used.
As a developer with a Java background I have to admit to liking Groovy over Python for scripting, not to mention for the API Platform groovy is part of the gateway deployment and SDK. Meaning it is readily available in its 2.x form (3.x is relatively recent and aligning to the latest Java idioms). We haven’t tested against Groovy 3.0
Thank you to Andy Knight for sharing with us some Java code which I adapted to be pure Groovy (removing external dependencies for processing JSON). The result is a script that can taken can be taken and worked into other scripts (which is what we have done for our previously provided scripts – Understanding API Deployment State on API Platform, Managing API Policy Versioning in Oracle API Platform, Documenting APIs on the Oracle API Platform). But this script can be used to get a token and display it on the command line or write it to file. Writing tokens to files is generally not good practise, but as a temporary measure when working on developing scripts arguably a managed risk.
The script can be found at https://github.com/mp3monster/API-Platform-Utils/tree/master/getToken and all the details on using the script can obtained by passing -h as a parameter. The important thing is to understand how to obtain the Client ID and Client Secret, the details of which are described at https://docs.oracle.com/en/cloud/paas/api-platform-cloud/apfad/find-your-client-id-and-client-secret.html
Last night was the first Oracle Developer Meetup in London for 2019. We were very fortunate to have Tomas Langer fly over to talk about the new micro container/framework being developed as an open source solution by Oracle.
Tomas, opened by explaining the evolution of the micro-profile being championed by the Eclipse Foundation who are now the guardians of J2EE also known as Jakarta and how the J2EE and Micro-Profile standards compare (in simplistic terms – micro-profile is J2EE stripped back to be simple and support what is typically needed in a microservice world).
In addition to talking about what can be done, Tomas described the kinds of features being developed, this includes:
- Bringing micro-profile support up to the very latest specification,
- More reactive persistence technologies support,
With the scene set, Tomas then worked through a series of live code scenarios starting with a clean slate and building Hello World in both the SE & MP models illustrating the differences in approach. This was then built upon to add the following capabilities:
- Tracing (using Zipkin leveraging the Open Tracing Standard)
- Dynamic configuration
- Security (including Signatures)
- Fault Handling (just MP)
You can get the complete example which uses Helidon in both configurations from Tomas GitHub.
In addition to Helidon itself on GitHub, there resources provided include rich documentation and examples of each key feature. Plus a Slack community, that if you contact any of the Helidon team will get you invited allowing you to discuss with the development team how to do things along with other developers using Helidon.
Helidon itself can be found at:
I have previously blogged on Helidon at Exploring Helidon – Part 1
We have been developing some advanced custom API policies for a client and in the process picked up on a few insights that didn’t even make into the API book. One of these policies is to provide an optimization around caching of API calls. The rest of this blog will talk about the tricks we have specifically applied to link an API Gateway to a caching mechanism and why.
Before I go into the details, I’d like to thank the Oracle product management team and particularly Glenn Mi at Oracle for their support getting through the deeper undocumented elements of the capabilities of the API Platform SDK.
Caching comes in may forms, and is motivated by varying reasons and not always the wanting the same behaviours. When getting into the subject of caching it is surprising how polarised people’s view points can be about which cache strategies are correct. The following diagram illustrates the diversity of caches that could appear in an end to solution solution.
Bringing together a caching technology in the Reverse Proxy model and an API Gateway makes a lot of sense. Data being provided to API consumers needs to be protected whether it comes from a cache or an active back-end system. At the same time you also want to exploit an API Gateway to provide analytics on API traffic, so any caching needs to be behind the gateway. But, if In front of an application layer then we can reduce the application workload.
When it comes to caching technology to partner with the gateway, there are a number of options available from Coherence to ehCache, memcache and Redis. We have avoided Coherence, whilst the gateway currently runs on a WebLogic server, we don’t want to need to unduly distort the performance profile and configuration of the Gateway by forcing a cache onto that server. In addition to which as Coherence is a licensed addition to WebLogic it raises difficult questions about licensing when deploying gateways (with gateways licensed based on logical groupings and API volumes but Coherence is licensed by OCPU). We also know that Oracle is moving towards having a micro-gateway which may mean we see the gateway engine moved onto something like Helidon (but this last point is my speculation).
We have elected to use Redis for several reasons –
- Available as a PaaS service with several cloud providers (AWS & Azure) so no setup or management effort but can also be deployed on-premises,
- Has an out of the box deployment that means cached entities can have a time to live (TTL) rather than needing to implement separate processes to expire cached values,
- The ability to make it scale through clustering,
This caching model also allows us to optionally allow application development teams to push into the cache directly results. So rather than waiting on TTL the cache can be refreshed directly or even primed, rather than having to create fake requests to prime a cache.
So I recently blogged (here) about the announcement of Helidon – the open source project from Oracle to provide a microservice app server that includes optional support for the J2EE Microprofile.
This is the first of what will probably become a series of blogs about Helidon, particularly in its SE form (non J2EE Micro-Profile) as Micro Profile and the wider J2EE model in general will have been documented more widely.
Helidon comes with a quick start example app implemented both in SE and MP forms. It is worth following the very simple instructions provided by the Helidon site to instantiate both versions of the Hello World app as it provides a good way to start to understand the differences in the way Helidon can be used.
The thing that really jumps out when you compare the code (for me at least) is the fact that the SE code being driven from values loading from configuration is more dynamic. The configuration can be sourced in a number of different ways from YAML files to etcd.So for our for first experiment we took the hello World app, and made the path /greet dynamic by loading the path from from some additional configuration. Enhancing the main with :
We can create URLs for greetings in different languages, and see the different instances of the Service object responding to the web calls. Whilst many may associate this approach with Node.js for me it felt more like the webserver multiplexer (MUX) such as Gorilla used with Go (you can see what I mean here).
Helidon and On the Road
Yes, I will be blogging more about Helidon as soon as I can, but presently wrapping up a white paper and running an API Design training session soon.
Yes it’s that time of year and Packt have launched their Christmas Promotion where the books and videos are all $5 (£4.76) including the two I’ve co-written and others I’ve tech reviewed.
Based on past trends, this is the best time to get any EBooks you want from Packt, there are other promotions but not as good as this!