We’ve added a new mindmap to our catalogue here. This covers the core of GraphQL. The catalogue contains both the image and a Word representation. The map is built based on a reading of Learning GraphQL by Eve Porcello & Alex Banks on O’Reilly.
To varying degrees, most techies are aware of the security vulnerabilities identified in the OWASP Top 10 (SQL Injection, trying to homebrew Identity management etc), although I still sometimes have conversations where I feel the need to get the yellow or red card out. But the bottom line is that these risks are perhaps more appreciated because it is easier to understand external entities attacking seeking direct attacks to disrupt or access information. But there are often subtler and at least more costly to repair attacks such as internal attacks and indirect attacks such as compromising software deployment mechanisms.
This, later attack Is not a new risk, as you can see from the following links, been recognised by the security community for some time (you can find academic papers going back 10+ years looking at the security risks for Yum and RPM for example).
- Survivable Key Compromise in Software Update Systems
- Consequences of Insecure Software Updates
- Attacks on Package Manager
- The Problem of Package Manager Trust
But software is becoming ever more pervasive, we’re more aware than ever that maintaining software to the latest releases means that known vulnerabilities are closed. As a result, we have seen a proliferation in mechanisms to recognise the need to update and deploying updates. 10 years ago, updating frameworks where typically small in number and linked to vendors who could/had to invest in making the mechanisms as a secure as possible – think Microsoft, Red Hat. However we have seen this proliferate, any browser worthy of attention has automated updating let alone the wider software tools. As development has become more polyglot every language has its central repos of framework libraries (maven central, npm, chocolatey ….). Add to this the growth in multi-cloud and emphasis on micro deployments to support microservices and the deployment landscape gets larger and ever more complex and therefore vulnerable.
What to do?
It’s been a quiet month for this blog, but I’ve been pretty busy with a raft of other activities…
- a recent article on our sister site – oracle-integration.cloud on RPA.
- I also appear in an interview with K21 Academy here.
- Reviewing a new book on Enterprise API Management for Packt which we would very highly recommend if you want to understand the more Enterprise perspectives of adopting APIs, particularly if you’re considering APIs as a potential new revenue stream.
- UK Oracle User Group committees for TechFest (having been reviewing the paper submissions it looks like it’s going to be an excellent conference in December) and Southern Summit (next week).
- Just launched a number of sessions for the Oracle London Developer Meetup, with another to be announced soon (Blockchain) and potentially two more before the end of the year (we’re working on the speakers now).
One of the things I am fortunate enough to get involved with on occasion is the Oracle Groundbreakers Podcast (previously known as the Oracle Developer Podcast) and something I have written about in the past, even as Oracle Developer Community (ODC) Appreciation Day post.
As a result of the recent Meetups on the subject of Helidon that have been occurring recently, we made the suggestion that Helidon is the subject of a Groundbreaker’s Podcast, net result I was invited to be part of the panel. The podcast was recorded a few weeks ago, and know available (here). Go check it out, as it includes the key contributors to the project Dmitry Kornilov and Tomas Langer.
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 micro-service 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 are 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
Chris Hollies’ slides can be found at here. As demo’s aren’t included in the deck, the following videos are alternatives:
Our second session, that I presented on how we can establish paths of transition that make it easy to adopt microservices. The presentation material for this is available here:
Oracle have announced another Open Source project called Helidon (Helidon.io) as a microservices platform built on top of Netty (which is built around a contemporary async model). If you look at the literature you’ll note two flavours one called SE which aligns to the programming characteristics or Node.js – asynchronous. The other is MP which aligns to the rapidly evolving J2EE MicroProfile which essentially follows a coding style along the lines of J2EE annotations.
Whilst it is perfectly possible to run Helidon based solutions in either profile natively, it is clearly geared up for running in any Docker+Kubernetes style environments such as Oracle Kubernetes Cloud (OKE) or even ACCS. Helidon website provides the means to quickly package your solution into Docker.
In both SE and MP forms the dependencies are hugely stripped back compared to the giants of WebLogic, GlassFish (now EE4J with the handover of J2EE to the Eclipse Foundation.
It does raise a number of questions what are the futures of WebLogic and Oracle support of EE4J (some answers here, but no Oracle specific)? WebLogic has never been the fastest to align to the latest J2EE standards (EE8 standard released last year should be become available sometime this year for WLS – see here), but today it is so central to many Oracle products it isn’t going to disappear, will it just end up slowly ebbing away? Which would be a shame, I have heard it said by Oracle insiders that if the removing the end of one component could be sorted then WebLogic could be easily be configured to have a small lightweight footprint.
The other interesting thing is what is happening to Open Source and what it might mean for the future. Up until perhaps 3 or 4 years ago the use of open source you would think of software made available on of a small group of key sponsored organisations such as Apache, Linux Foundation, Eclipse which through its governance framework, provided levels of equality and process. As a result, levels of quality, trust crucially married to strong level of use and contribution that meant that to extrapolate Linus’ Law – bugs could be weeded out quickly and easily. However with the advent of services like GitHub, whilst it has become easier to contribute and fulfil Linus’ Law. It also means that it is very easy to offer a solution that is Open Source. But, doesn’t necessarily garner the benefits of Linus’ Law and the other preconceptions we often have about Open Source such as it is/can be as good as a commercial solution. After all, throwing code into GitHub does not guarantee many eyes/contributors. Nor does it assure the governance, checks and balances that an Apache project, for example, will assure.
It is important to say that I am not against github, in fact, I am very much pro, and use GitHub myself to host utilities I make freely available (here). The important point is we have to be more aware of what open source actually means, in each context and can’t assume it is likely to have a strong community driving things forward, and critically dealing with bugs, and ensuring quality assurance processes are realized.
Helidon joins a number of other offerings in this space such as Micronaut (also built on Netty). Micronaut takes a different approach to Helidon by adopting a strong inversion of control/injection approach. In and in some respects feels a bit like the earlier versions of JBoss Application Server (now known as WildFly) which had a small footprint and made good use of Spring. This is in addition to Spark and Javalin. There is a good illustration of the different servers from Dmitry Kornilov shown below and the associated article can be seen here (who also happens to the Lead Engineer for Helidon).
Unlike Spark, Micronaut and a couple of others, Helidon only supports Java today rather than JDK based languages such as Kotlin and Groovy for example but is the only solution that can cover both the Micro Profile and Framework domains. It also has a challenge in terms of getting established, Spark has been around since 2015. Javalin appeared in May 2017. The J2EE Micro Profile standard is also driving a lot forward progress, so getting established will continue to get harder. Liberty, another Micro Profile solution is based on IBM WebSphere and Thorntail has links to WildFly (more here). We hope that it will make good headway with a Reactive engine in the form of Netty and avoiding IoC or introspection from the core should mean it will be very quick (particularly during startup) but it needs to show its value differentiation and importantly build a strong community contributing to it.
We hopefully will get the chance to further experiment with Helidon and write more about it here.
Last month I was fortunate enough to have been invited to participate in another Oracle Developer Podcast. Rather than focusing on specific technologies, this focused on more how the thew job market is changing for IT and what might be driving change, and how things may change in the future. Check it out here.
As ever thanks to Bob Rhubart of the invitation, and putting together these excellent recordings.
If you read press around Java you’ll have come across references to GraalVM. So what is it and why would I use it?
Because the languages are described through the same framework this means the work to optimise the VM performance becomes a lot easier.
It would be easy to assume that using the framework would mean the execution of languages using this mechanism would slow be slower. But, Truffle works by translating the code to standard byte code before execution, so ‘ported’ languages are now no less efficient than Java come runtime.
There is an interesting bi-product of this model, that at runtime with the right object exposures it is possible for multiple languages to interact with the same object easily, no JNI or dropping to the lowest common denominator such as a JSON+REST. This does raise interesting possibilities for thick client solutions or polyglot monoliths!
Probably one of the biggest pay offs for using GraalVM and its ability to run multiple languages is that the base Container images can be simplified as you don’t need different container images. This makes the work of patching and testing configurations of these container a lot simpler as the permutations will drop, particularly for organisations that have wholehearted embraced polyglot micro-service ideas.
One common reason for changing implementations of the JVM particularly at the more performance sensitive use cases (checkout Azul as an example) is how the JVM is optimised and the JIT algorithms and processes particularly the Garbage Collector work (checkout this list of JVMs. For example GraalVM will provide better performance for processes that less heap hungry than Oracle’s JVM.
It is interesting that Oracle are investing in a new VM when it wasn’t that long ago that JRockit was wound down. Given the legal dispute between Oracle and Google (see here) the new VM would give Google a means to escape from the copyright breaches and retain support for Java.