Category Archives: PostgreSQL

Hey JAVA-developer, why don’t you love your database


Why this post?

Partly, this blogpost is a result of a promise to Lukas Eder. Basically my vision adheres quite nicely to the “Thick Database” driven by Bryn Llewellyn and Toon Koppelaars who, understandibly, drive this from an Oracle perspective.
It –more than of course- also nicely fits EnterpriseDB or even vanilla PostgreSQL database landscapes.

There is apparently still so much confusion in the world on the how, why and what of good application development and architecture that I decided to chip in my bit. I think I have a bit of an idea on how this aught to work and I also think it is not a half bad idea, plus a couple of people whom I highly regard, seem to agree with it. So here goes…

Traditionally

Traditionally there is no big love between application developers and their persistence-store. I don’t really know why because I never found the opportunity to do a real inquiry, but I think I have a reasonable understanding.

Basically there is constantly the enormous pressure of delivering new features and functionality. So much even that the basic development work, the more “boring” and “time consuming” things -why pay now, if you can also pay later- get postponed. Things like peer-reviews, (integration) testing, technical design… Basically, more people means more features.
If even these things get too little attention, why would something like an overpriced library-box get more attention? Not to mention these DBA’s you need to pass to even get close(r) to this library-box…

Here are my four reasons why I think
it should deserve a chance!

1. Easier

Plain and simple. It is easier. If you take a structured query language like PL/(pg)SQL, it is basically easy. Founded on the programming language ADA, it is easy to understand and one can quite easily build a number of routines, procedures, packages, functions to let the database chop and glue data and just deliver the results for your application to consume.
It saves you the time of having to (re)write some of this more complex stuff in your application or perhaps even over a several applications.

2. Quicker

As said under the first point: build once, use many times. By creating mechanisms in the database, you get the opportunity to think about the separating data manipulation mechanisms from data representation mechanisms and where you want to put which specific function. Of course, this decision process takes a little extra time in the beginning, but will repay many times over as your projects grows and gains meaningful complexity (is there something like “meaningful complexity”, well, yes…).

Quicker also is in operational response times. Querying a stored procedure will bring agility to your application in a sense that this stored procedure will be much quicker in getting you the answer than if you do this in a distributed (middle-ware) environment. These stored procedures can be accessed through REST-endpoints, giving flexibility and the possibile desired disconnect between the database and the application layer.

3. Cheaper

Powerful, because you are and you remain close to the data. No data transportation overhead, no latency. These kinds of slimming down, mean less requirements to infrastructure and distributed capacities (either hardware or (virtual) “cloud infrastructure”. This slimming down frees up budget which can then be spend on the more meaningful bits and pieces of your application.

4. More consistent

Finally, I think this approach brings more consistency. As you do things near the data it lives on, near the processing power you depend on, you also get single access paths to specific bits of your data, to specific constructs that drive the value of the application you are building. Through this, it does not matter from where you call this service, REST-endpoint, stored procedure, or whatever you call it, you always get the same answer, driving a consistent decision process based on that application.

And if ever something changes, there is also just one place for you to ensure these new requirements are added. Voila, consistency throughout your application landscape, as all that depends on this data-set gets this uniquely updated information.

The magic of working together

There is a lot of misunderstanding between DBA’s and Developers. I have been in both roles at some point and I have seen this happen first hand. One of the things, though, in that force field, I have learned, is the power, the joy and, through this, the magic of working together.
In the end, we all have the same goal, which is furthering our business by being the best at what we do. This means, for a developer, meeting feature request, short development cycles, quick delivery and as much as possible, get it right in one go. For a DBA this means making sure the database stays consistent, performant and available. And, in extension of that, for operations it means that the final product must be easily and quickly deployable to enter into an uneventful and dependable life-cycle.

Bringing together these seemingly conflicting disciplines is fun! By investing a little time in exploring the other disciplines, you will find common drivers, in a sense that everyone want the same thing. By getting over nearly religious initial differences, you will find magic in the combination. You will reach your goals earlier with the bonus that your co-workers will also reach their goals earlier and have a better end result than you dreamt possible.

True JAVA-Champion

Coming from another world, I do not know the requirements for becoming a JAVA-Champion. I imagine it to be not too much different from other recognition programs out there… But…
If you create more features and functions and you are able to run your application with greater concurrency on (way) less platform-power. Thus increasing the RIO on your application, this makes you a true Champion of JAVA and your business!! If you are able to combine this with some magic in your cooperation’s…
Believe me, it is more fun in the end too!


Riga Dev Days 2017, new experiences in many ways.

Riga Dev Days 2017

General

It has been a while since my last blog-post.
One of the reasons is my shift from closed to open source software, databases more specifically. More on that in a later blog-post.

The reason for already mentioning this is this strange hybrid (what a popular word, these days) situation that I am in at the moment.
Thanks to the super enthusiastic, flexible and tenacious organization-team of the Riga Dev Days, I was able to participate.
Happily boarded the Air Baltic flight, I went on my way to Riga!!

Being new at the broader conference scene, I enjoyed being at a mixed source developer conference. Besides the usual suspects – some of which are my best friends – I got to meet many interesting new people.
One of the key phrases of the day is: “the more you learn, the more you realize you know nothing – John Snow…” and it’s true! You never stand to think about it, but the wealth of subjects is just tremendous and the combined knowledge at events like these is down right “Yuge, it’s awesome, tremendous!”

Day one

With a day like this, time flies. Between session (and during sessions) there are discussions, a bit of work and catching up to do.
Still I managed to catch a few sessions, like the one from Michael Hüttermann who made a clear and well rounded case regarding CI/CD in a DevOps world. A nice insight into the effort that goes into what’s behind the proverbial “push of a button”.
Another example was that by Marcos Placona about the many (and very basic) things that you have to keep in mind wen building apps. There is no silver bullet and the best you can achieve is to discourage the hacker so much, they move on. Much like securing your house, do to speak.

The day ended in the medieval basements of Riga, where we had some really good medieval food. Life is good…, well…, it has it’s moments!

Day two

The keynote address by Edson Yanaga, which kicked off day two of the Riga Dev Days, was quite interesting.
Shortening development and deployment cycles and shrinking feature release sets actually helps improving software and deployment quality by creating faster and more accurate feedback loops. By looking at these concept in this way, buzzez like DevOps and Agile actually get some hands and feet. One of the lessons, though, is that doing things this way do not eliminate work or automagically solve various issues for you! It will help in getting predictability and continuity into your software development processes.
A nice eye-opening remark finally, was… “no, I don’t pay you to make something work on your computer, I pay you to make something work on my computer(s)!!”

Another talk I was able to attend was around Blockchains. Something I knew nothing of and was actually quite interested in. Nick Zeeb took us through a very lively and very animated tour of what actually a Blockchain is and what the awesome potential of this technology can be. I was impressed.

With this, the second day draw to and end and therewith also my turn “in the pit”. As this event is held in a movie-theater, every room had a sloped tribune, which was often packed with enthusiastic participants. I had the opportunity to share my thoughts on the comparison between PostgreSQL and Oracle.
The session was very well attended with a lot of questions regarding the possibilities of using these other technologies in scales that were not really considered before. You can find a recording of the actual presentation here as soon as it comes available.

Riga Dev Days was a good conference. I would recommend everyone to either attend or submit an abstract for their event in 2018!!