Enterprise grade Java.
You'll read about Conferences, Java User Groups, Java, Integration, Reactive, Microservices and other technologies.

Tuesday, March 28, 2023

Public Speaking in 2023 - Some thoughts and 10 reasons.

15:04 Tuesday, March 28, 2023 Posted by Test No comments:
,
Some people have asked me, why I don't travel and speak at conferences anymore and I wanted to write about it anyway. So, here it is:

There are in fact some reasons. And while I initially thought I get away with just tweeting the few points,
I realised it’s more.

Also: Don’t think this is a goodbye or my official resignation as public speaker. It’s more my personal decision making list that I apply to every single request that reaches me offering a speaking slot somewhere. I will be around. Probably on-stage or on-cam occasionally and as much or little as you like to hear my wonderful German accent. I repeat:
Not a goodbye! 

1. Health. The most important one is that it's not good for my health. I've done this long enough and I'm at the point where I've seen hundreds of events and racked up a distance that covers 25 times around the world. It's just not as much fun anymore as it used to be when I was 10 years younger ;-) 

2. CO2. TripIt estimates a total of 250 tCO2 for this just for the last 10 years. And I'm sure I missed some trips. I've done my damage. That's multiple times as much as an individual should have "consumed" during that time. 

3. Online. We came a long way with streaming and video. I built out a little studio in my basement and can do a ton of presentations remotely. Yep, I miss the vibe. Yes, I miss seeing my audience. But this is the best I can offer now. And the thing I like the most is, that I can wear what I like and don’t have to put on shoes :)

4. Children. My kids aren't grown up yet. And I've missed way too many days already. So, I prefer to be with them over everything else. Yes, even conferences with amazing people and friends. Something I realised late is that there’s not a lot of legacy we leave behind. The important one for me are the two. I want to make sure they are able to stand on their own feet and get an opportunity to learn what’s necessary. Nobody knows how much time is left. Don’t read too much into this sentence btw. It reads deeper than it probably should.

5. Topics. Our industry is amazing and we keep reinventing the wheel over and over calling it different names. I've seen a lot. And it's harder to excite me year after year. I'd really like to not jump on every single new thing over and over just to be accepted at events. Let's try talking some sense into topics again and cover some basics. Nothing I could get accepted as paper at conferences anywhere. Seems as if we're all just looking for the next cool aid. That's not what I belive enterprise development should be looking for. 

6. Budget. Everyone has been waiting for this. Macroeconomics aren't looking good. Money isn't available as it used to. Even coffee is shitty expensive. I want to do my part and not be part of the problem we're all seeing. If there's no reason to go but to talk 45 minutes in front of a crowd but it involves 2+ days of travel? I don't think this is the right thing to do right now.

7. Beer. Or alcohol and parties. I'm not a big social guy anymore. My life changed. The pandemic changed me. I haven't touched a drop of alcohol in a solid year and I don't think I want to anymore. It might have a fair place in social evening events and I am not judging anyone for enjoying it but I can't envision myself drinking water in the midst of beer central. And I also don't want to just stay at my hotel. Maybe we have to rethink how we run the social parts of conferences. Maybe I am just getting old and boring. 

8. Schedules. My job changed plenty of times in my career. And I always had tight schedules. But working with an amazing team on tomorrows technologies and things that make developer’s lives easier is consuming a lot of attention. While I’ve been pretty good at working from wherever I wanted whenever I had to, I am enjoying the deeply focussed times more and more. It’s easier to get things done and meet deadlines without a toll on my health and a lot less stress. Also, I can fit my workout schedules into my days and not mess around with jetlag and timezones. 

9. Political situation. Thankfully I was born in a country that lets me travel almost everywhere. And I have been traditionally very picky with choosing my destinations. The short list grows smaller year after year with recent events making it even harder to see some of the amazing engineers and developers in the east. I do not want to have to chose where I can and can’t go. 

10. Next generation of speakers. I was tempted to start this sentence ranting about my age again ;) But you’d read too much into that again ;) There’s plenty of talented, engaged, curious, motivated, brilliant, young speakers out there that I think belong on stages. Across the world. Give them the opportunity to grow their career. To share what they know being in the stage light. There’s no point in seeing the same old dudes at every event talking the same things. Broaden your horizon. See someone talk who you’ve never listened to. 

Turned out, it became not less than 10 reasons for me to be very picky with speaking engagements. And just maybe I have written this more for myself than for anybody else to have a good overview to point people to when I am asked about the why. 

Friday, November 11, 2022

Dieting vs. Nutrition vs. Rethinking my lifestyle

14:23 Friday, November 11, 2022 Posted by Test No comments:
, ,

Found this at #AMS this morning. 

I talked to some people about how I managed to lose weight. Some were honestly surprised and happy for me but still curious about how I made this happen. Some other might want to learn from what I did and start over themselves. While trying to explain it with many words person to person, I finally had some time to write down my thoughts a little more detailed and cohesively. This is somewhat a self-reflective retro perspective and not advice or self-help blog. I summarise what and why it worked for me. Take what helps you and leave the rest. I am not looking for recognition, I am not looking for cheers, I love sharing and something in me hopes that this might help someone else. This is why I’ve written it down. Keep your negative thoughts or advice to yourself. 


I'm not a doctor or have any medical background. So, take this as what it is: an opinion from a single guy. I've been under medical surveillance on my journey. Still am. You should be too. Get a blood check, take a look at your vitamin levels, make sure you know how much and what kind of sport you're allowed to do at the weight you're at. That means, you’ll need to see more than one doctor. Also, don’t go to my GP. In general they should be the first to help you. Mine is different and I had to find a specialist that knew how to balance medication and sport. More on this later. Generally: Don't make it worse! Also: this is not your medical advise posting. I'll focus on what worked for me and my personal approach. This might not work for you. This probably isn't the wonder pill you're searching for. Just food for thought. The only food without calories, btw.


I see all of this as a journey by now. After almost a year, I can confidently state that I've somewhat found my pace but it'll not be back again to the old life. I'll explain the why later on, for now it's important that I consider what I'm doing not a diet but a change in lifestyle. In my eyes this is crucial because it takes out the timeline. Many times before I thought, I'll loose a couple of kg and be done until the next time. Thinking about dieting in terms of sprints or exceptions from your life makes it sound bearable. But to me that is part of the problem and reason why I went through this some times before. I've always seen it as dieting and as such as an exception. It never stroke me that "my normal" could be part of the problem. I've always been and still am pretty self confident I guess and not questioning myself enough ;-) So, turns out, I had to rethink what I considered normal and adjust my approach. 


Being successful in changing it started with changing my mindset. I've lost weight before and gained it again. What drove me on this journey were side effects of medication I had to take because of me being overweight. Your motivation will for sure be completely different. What's important in my eyes is that you realise for what you're doing this. For your health and for yourself. Misinterpreting other people's expectations or felt standards and trying to be motivated to reach them never worked for me before. Having a medical reason to do this was key for my mind to finally click.


Let's talk about how I envision this calories thing to work. In my mind, my body is like a car. With extra gas tanks in the trunk and some other places. Like with a car, the amount of gas I'm using is equal to the distance I can travel. If I travel longer distances, I need more gas. Idling requires less gas. Thankfully, unlike a car, you can't turn your body off. Your body is idling even if you're not moving. It consumes “gas” all day and night. This is what I call base calories or resting energy. When I'm taking my body out for a drive, it'll consume extra or active calories. When I am putting more gas into my tanks than I need, the car get’s heavier and grows in size. I'm smirking by the thought that my butt grows when I'm putting too much gas into my car. And yes, it’s more complicated, sugars or other good/bad carbohydrates and proteins and vitamins and and. Simplification always helped me to understand complex things better. Might be the reason I am fine with this simplistic world view. The formula to success for me is: “base calories + active calories >= calorie intake”. That is basically my mental model of how all of this works. You have all rights to scream: “that is not correct”! and be done reading this post if you like to. But this simple picture helped me to understand what’s going on. I needed to make sure there’s relatable and easy to apply logic available to me whenever I got to the point arguing about a cookie or two extra ones. Remember when I said, find a doctor? This is why! You can fulfil this equation and be successful by eating just cookies and other simple carbohydrates all day. But your car also needs more than gas: Oil, engine checks, break fluid, new wipers, wheels from time to time! 


Eating right is the key to get your car everything it needs. I think I am done remembering you about your maintenance windows (doctor!), but continue to refill the necessary working fluids and ingredients. Learn a little about what you are eating. I had to start with a very simple diet to get onto the right track. As I am a very binary person, I needed simple guidelines I can easily execute on at the beginning. I started changing my breakfast. From a full English breakfast to cereals. 40g oatmeal, 110g yoghurt, a handful of various nuts crumbled into it. Add some milk and you guessed it: Coffee. Roughly 500kcal to start the day. A year after, that is still my breakfast. I find it surprisingly hard to find the simple ingredients at hotel breakfasts, but I manage to replace/resize the portions/ingredients as I have choice in the meantime. Lunch and or dinner were a little more tricky. First action I took was to scrape all takeout from my list of options. And skip as many carbohydrates as possible. Replace normal pasta with pea or soy based versions. Leave potatoes and derivates out. It came down to a lot of vegetables and very little meat. While my girls slowly turned into flexitarians over the last years with little exceptions for white meat, this didn’t had to change a lot. We’ve skipped minced meat more often and switched to a mainly plant based nutrition. Salad included. I’ve tried keeping my palette very small in the beginning. To give me the guardrails I am talking a lot about in technology but also to understand the amount of energy in my food better. Yes, I have been counting calories again. It is somewhat unavoidable if you need to figure out the distance you can go with your car. Over time I started adding things back in. Going almost all vegetarian had a couple of positive side effects. I’ve never been hungry. I could eat as much as I wanted (almost). And all I had to concentrate on was the urge for things I did not allow myself.
I almost forgot one of the bigger pieces here though. I am not drinking any alcohol anymore. Since last December. Remember that I told you that I am a binary person? I can only do or don’t do things. There’s very little in between. A decent Gin-Tonic has around 250kcal. My go-to drink very quickly becomes the equivalent of a full day's energy demands! So that was not cool and had to stop.


So much for the intake side. You also need to find out about base calories and resting energy. There are very good and medically approved ways to find out about it and your doctor can help you with figuring it out. I did this on my own. Or almost at least. Apple to the rescue. Not the fruit but the company. I’ve had various Watches before and they turned out to be an easy health device to built into my days. If you open the fitness app (won’t hurt, go for it!) and take a look at the hated rings, you’ll clearly find your move and total calories. Subtract move from total and you have your resting calories. Consider it an estimate. And it ultimately didn’t matter to me in the first few months because I wanted to reduce intake aggressively to lose some of that excessive “gas” storage in my butt. But now I found out where my base is. My resting energy hovers around 2k calories/day. Whatever exercise I do on top consumes extra. So all I had to do is stay below with my intake. And this went insanely well. I lost the first 10kg within the first four months. 


I just recently were able to run almost 3km distance. That is 20 minutes. Running. Unthinkable for me, just some months back. Sitting at the airport right now waiting for my flight back home, I am aching to get moving again. It hasn’t been like this from the beginning. Moving has been a burden for me. Sport an unthinkable activity. BUT it is your magic key. I understood this from the beginning. But understanding and the ability to execute are two different things. I had to overcome a lot of mental hurdles to get myself moving at first. Again, a praise to Apple. Because with every new Watch you get a free couple of months worth of Apple Fitness+. And while I’ve paid for various gym memberships in the past few years, I’ve started working out at home. Alone. For myself. Without anybody (!) watching. I wanted to be left alone. The sweating, hard breathing mess I was making some first movements in front of the TV. And I have to acknowledge that I have never been excessively overweight. According to my BMI back then I just slid into being considered “overweight”. Still did not realise at that time how many limitations I already silently accepted in my movements. Jamie-Ray Hartshorne and his 20 minute beginner HIT workout marked the start of my success. While he almost killed me at first, it got easier over time. I’ve done this workout every single day. For a couple of months. Nothing else. I did not care about move or activity rings. I just did that workout. Until it started to be too easy. I slowly and steadily expanded my choices of trainings and started mixing in other trainers and programs.


HIT is amazingly exhausting. HIT or High Intensity Training aims at intervals of excessive heart rate and rest times. It basically drives your car in the upper RPM ranges. And while this can be fun, and for sure helps burning calories, it isn’t the only thing my car needed. Our cars are pretty amazing things. The extra “gas tanks” they build out over time are meant as savings for bad times. Unlike with bank accounts, these savings quickly build up but can’t easily be withdrawn. Protein is a lot easier to convert into energy for our “cars” than fat is. What happens mostly, when you start loosing weight, you start losing muscle mass. Which is exactly the opposite of whats desired. Because muscles not only protect us, they also burn more base energy as fat does. This made me switch to strength trainings over time. Still in front of my TV. Still with Apple Fitness+. Up to today. I am bringing in more variety for sure. Extensive walks (sometimes up to 9min/km for as long as 12km length) or indoor cycling when I am travelling or just recently running. My overall “move goal” is around an hour a day. And move in this case really means: Sweating. Getting my heart rate up to at least 120 bpm for a reasonable amount of time. 


That’s it. The whole secret. I am off medication since a while. My blood pressure normalised and I can walk AMS Security to gate without breaking a sweat. I can wear cloths and brands again, I thought I’d never own ever again. (If that is a good thing or not might be a different blog post though…). Most importantly, I feel good. Like in: am at peace with myself. No feeling of restlessness anymore. I sleep better. I am more relaxed (most of the time) and have a lot more energy to focus on things. It has been a challenging but baseline positive experience for me. And even if your reading comes to an end here, my journey doesn’t. There’s no going back to what I used to call normal before anymore for me. THIS is my new normal. Eating (more) healthy, exercising (a lot) more, taking care of myself (more than ever before!). Stay healthy y'all.

Tuesday, May 3, 2022

Modernizing Enterprise Java

13:01 Tuesday, May 3, 2022 Posted by Test No comments:
, ,

I haven't blogged in 4 years, 10 months, and 1 day. A long time. Many things have happened, and I have continued my journey mostly on Twitter and LinkedIn. But there's one thing in particular that I really want on this blog: My new book. Already released on October 21 but is still available as a free PDF download from the Red Hat Developer website. 

Thank you to my co-author Natale Vinto for an amazing experience and result! 

While containers, microservices, and distributed systems dominate discussions in the tech world, the majority of applications in use today still run monolithic architectures that follow traditional development processes. This practical book helps developers examine long-established Java-based models and demonstrates how to bring these monolithic applications successfully into the future.

Relying on their years of experience modernizing applications, authors Markus Eisele and Natale Vinto walk you through the steps necessary to update your organization's Java applications. You'll discover how to dismantle your monolithic application and move to an up-to-date software stack that works across cloud and on-premises installations.

  • Learn cloud native application basics to understand what parts of your organization's Java-based applications and platforms need to migrate and modernize
  • Understand how enterprise Java specifications can help you transition projects and teams
  • Build a cloud native platform that supports effective development without falling into buzzword traps
  • Find a starting point for your migration projects by identifying candidates and staging them through modernization steps
  • Discover how to complement a traditional enterprise Java application with components on top of containers and Kubernetes


Tuesday, June 27, 2017

Reactive Microservices with Lagom & Java - DZone Refcard

18:20 Tuesday, June 27, 2017 Posted by Test No comments:
, , ,
Wow. I haven't blogged here in a while. Good news, the blog isn't dead and not going to die anytime soon. I'm just spending a lot of time blogging over at lightbend.com/blog (Have you seen the monthly Lightbend Tech Digest yet?) and also help developing additional content around our open source projects. Mostly Lagom. And I am very happy to announce that my first Refcard was published on DZone today: And it is about Lagom, obviously!

Refcard #240
Reactive Microservices With Lagom and Java
The Reactive Microservices Framework

This Refcard helps you with your first steps in Lagom. Lagom is a framework that helps you to build reactive microservices.

Most microservices frameworks focus on helping you build fragile, single instance microservices - which, by definition, aren’t scalable or resilient. Lagom helps you build microservices as systems — Reactive systems, to be precise — so that your microservices are elastic and resilient from the start and don’t require extra plumbing around them.

Building Reactive Systems can be hard, but Lagom abstracts the complexities away. Akka and Play do the heavy lifting underneath and developers can focus on a simpler event-driven programming model on top while benefitting from a message-driven system under the hood. Lagom provides an opinionated framework that acts like guide rails to speed you along the journey. Lagom tools and APIs simplify development and deployment of a system that includes microservices.

Don't forget to check out your weekend reading list:

Thursday, February 16, 2017

From Microservices to Distributed Systems - Survival guide for Java Developers

10:15 Thursday, February 16, 2017 Posted by Test No comments:
, , ,
It kind of feel like the hype for Microservices is slowly coming down to earth and our industry is starting to realise, that a system according to the architectural paradigms behind Microservices can't easily be created by just exposing some HTTP interfaces on top of existing components. We do seem to have agreement on the necessity of having service optimised infrastructures, cultural and organisational changes and last but not least the outer architecture or orchestration for these architectures. The parts, that many Java developers still seem to struggle with are the concrete system architecture and the fact, that Microservices are nothing else than Distributed Systems. Unfortunately it's exactly these knowledge areas that decide about success of failure of your project. For a little bit of background, I suggest reading the wonderful InfoQ interview with Uwe and Adrian done by Daniel Bryant.

Why Microservices again? Can't I just be happy and write EJBs and Servlets?
The key idea with microservices are the properties that support independence of the rest of the application landscape and quick evolvability. Additionally, they should scale independently and require less resources than application server based applications. In a world with constantly changing business requirements and growing number of application clients, centralised infrastructures are getting way to expensive to operate and scale towards unpredictable load or load peaks. If we all would be stuck with application servers, we wouldn't have Netflix, Twitter or Amazon. So: No. You can't just stay where you are.

Microservices are Distributed Systems. What's so special about them?
The original definition of a distributed system: "A distributed system is a model in which components located on networked computers communicate and coordinate their actions by passing messages." (Wikipedia) And this is exactly what happens in Microservices based architectures. The individual services are deployed to cloud instances, physically running somewhere and they exchange messages. This is a big difference to how we used to build centralised applications. Instead of having a bunch of servers in our datacenter that handle all kinds of synchronisation, transaction and failover scenarios on our behalf, we now have individual services which evolve independently and aren't tied to each other. There are some fundamental challenges that are unique to distributed computing. Among them is fault tolerance, synchronisation, self healing, backpressure, network splits, and many more.

Aren't Distributed Systems what everybody calls Reactive Systems?
It's more complicated than that. And honestly, there is a lot going on with the word "Reactive" itself these days. To build an application or system out of individual Microservices, you need to use a set of design principles to make them Reactive, Resilient, Elastic and Message Driven. If that sounds familiar, you are probably right. The definition from the Reactive Manifesto. A distributed system which implements the four traits of the Reactive Manifesto is what should be called a Reactive System. You can read more about the design principles of Reactive Microservices Systems in Jonas' book. The Lagom framework is build on those principles, but let me be clear, that you don't necessarily need a specific framework or product to build these kind of applications. Some of them just make you a hell lot more productive and your operations more effective. Hugh McKee has another free book on design principles for Actor based systems.

What are the options to build a Microservice based System?
I personally see two different trends of solving the problems related to Microservices today. First is to push the problems down to orchestration or datacenter operating or cloud systems like DC/OS, OpenShift, Cloudfoundry, and alike.  The second solution is to natively handle them on the application or framework level (Akka, Vert.x, et al).

One container per service, or why an Anaconda shouldn't swallow a horse.
Let's look a little more detailed at the first approach. Write a microservice, package it together with the runtime in a little container and push it to the cloud. As we're all full stack, DevOps developers these days, it's easy to create the meta information needed for cloud based runtimes. Thanks to my bootiful service, all relevant monitoring information is exposed already and I can easily detect failing services and restart them. And this for sure works. You can even use a full blown application server as Microservice runtime. Plus, there are a lot of magic frameworks (NetflixOSS) which help with fighting the distributed systems challenges. The drawback for me personally is the tight coupling with the infrastructure in this case. Your system won't be able to run on anything else but the platform of choice. Further on, they suggest that you just need to use containers to solve all problems in the Microservices world. Looking back at the Reactive Manifesto, these type of systems won't help you with the requirement to use messaging between services.

Microservices without Containers? That's Peanut without Butter!
True. Containers do one thing very well. Package the complete stack in a controllable way into a deployable unit. They are isolation mechanisms on the infrastructure level. And having a container standard might actually be a good thing. So, keep your containers. But you need more.  So the key to building Resilient, self-healing systems is to allow failures to be: contained, reified as messages, sent to other components (that act as supervisors), and managed from a safe context outside the failed component. Here, being Message-driven is the enabler: moving away from strongly coupled, brittle, deeply nested synchronous call chains that everyone learned to suffer through…or ignore. The idea is to decouple the management of failures from the call chain, freeing the client from the responsibility of handling the failures of the server. No container or orchestration tooling will help you to integrate this. You are looking at Event Sourcing.  The design concepts for an event-driven architecture, using event sourcing, align well with Microservices architecture patterns.

Reactive Programming, Systems, Streams: Isn't that all the same?
Reactive has become an overloaded term and is now being associated with several different things to different people—in good company with words like “streaming”, “lightweight”, and “real-time. ”Reactive Programming offers productivity for Developers—through performance and resource efficiency—at the component level for internal logic and dataflow management. Reactive Systems offers productivity for Architects and DevOps—through resilience and elasticity—at the system level, for building Cloud Native or other large-scale distributed systems. You should really take the time and read how Jonas Bonér and Viktor Klang explain the individual differences between them.

Where can I learn more about how to design Reactive Microservices?
James Roper did a great talk at last year's Reactive Summit and took a hands on look at how the architecture of a system, including the flow of data, the types of communication used, and the way the system is broken down into components, will need to change as you decompose a monolith into a reactive microservice based system.


I did a talk at the CJUG about CQRS for Java Developers which gives you an intro. If you have particular topics that you are interested in, please let me know in the comments.

More Reading for you 

Tuesday, December 20, 2016

No, being wary doesn't hurt Java. A comment about Java licensing.

10:19 Tuesday, December 20, 2016 Posted by Test No comments:
,
Screenshot from the Oracle Website (source)
So. Oracle want's to make money from Java. And The Register published a very polarising piece with a super catchy title about it. According to their sources, "Oracle is massively ramping up audits of Java customers it claims are in breach of its licences". While the Twitter-verse went ballistic about people criticising Oracle's behaviour, I want to take a minute to recap, why I am against this method and clarify, that the normal developer and user have nothing to fear!

People complaining about Oracle are hurting the community
You know me in and around the Oracle-sphere since many years. And tweeting at the moment is probably the most important part of how you can get the lastest news about me. I rarely post on this blog lately, because there is so much to do and I do a bunch of posts for my employer already.
The tweet I send was basically the title of The Register article and replies and reactions implied that just by spreading a FUD article, I am hurting the community. Let's look into the details.

Are Java developers affected?
NOTE: First of all, I am not a lawyer. This isn't mean to be a legal advice! If you are in doubt over your compliance to the BCL, contact a licensing lawyer, your local Oracle User Group or Oracle.

NO. We are covered. The Binary Code License (BCL) explicitly mentions:

"Oracle grants you a non-exclusive, non-transferable, limited license without fees to reproduce internally and use internally the Software complete and unmodified for the purpose of designing, developing, and testing your Programs."
(BCL, April 2013)

There are some cases you should be aware of.

"You may not use the Commercial Features for running Programs, Java applets or applications in your internal business operations or for any commercial or production purpose, or for any purpose other than as set forth in Sections B, C, D and E of these Supplemental Terms."
(BCL, April 2013)

- If you use a commercial feature in your local environment and stage it to test, you might not be covered.
- If you are accessing any of the  JMX MBeans under oracle.jrockit.management and bea.jrockit.management to enable observation of a running JVM, independently of the monitoring solutions, you are not covered.
- Flight Recorder, Mission Control and everything mentioned in the below linked PDF are commercial and you can only use them on your local machine.

A complete list of commercial features is listed in Table 1-1 on page 5 of the Java SE product edition description (PDF). As a general rule of thumb, make sure to NOT use the -XX:+UnlockCommercialFeatures option.

This mostly affects companies who are already Oracle customers and have access to the commercial features, that are most interesting (e.g. MSI Enterprise installer). Funny enough, WebLogic for example includes a Java SE license (random product link).

I'm still afraid, what are the alternatives?
You can go with various alternatives. First of all, there is the OpenJDK itself. Windows builds are a little tricky, as they are not available directly from the project. Only latest development releases are available for Windows. But you can also get binaries from Azul (Zulu) and Red Hat. If you are a Red Hat customer of any JBoss Middleware product, you also get support from them.

Why do I dislike what Oracle does?
I do like, that Oracle is sponsoring the Java development and I acknowledge that they invest significant manpower into the project. But that doesn't get them a carte blanche to get away with everything.
My main point of criticism is, that Oracle makes it easy to accidentally use commercial features. And yes, as people on Twitter pointed out, you should have just read the license and know about it. But as a matter of fact, I believe that separation of concerns is a good design decision. Instead of directing potential customers and users from the OpenJDK site to java.oracle.com with the comment "which are based largely on the same code" and not even distantly mentioning, that these do contain commercial features which you aren't allowed to use, it would be easier to have separate commercial and open source builds.

If you click around on the Oracle Java website you have a couple of hints at Licenses. But they don't get you the full picture.
Java SE Licenses overview page (source)

And there are plenty of more examples. The number one search result from (my personalized) Google for "Java License Business" leads to this page for example. Speaking of misleading information, I think, this is a good example. If license conditions aren't well known, it's also easier to change them. Which probably hasn't been the case, since the BCL PDF linked was last updated 02 April 2013.

My personal opinion is, that it can't be healthy for the community to stop improving. And improvements don't come from silence. Unfortunately, Oracle doesn't have a great history in listening to their communities which also might lead to some catchy and inappropriate headlines from time to time. Nevertheless, let's stay wary and keep communicating things that could improve. It'll help the community more than it hurts in the long run: Open communication is a sign of a healthy community and the way it deals with feedback and criticism is the gauge for their values.

Friday, September 16, 2016

Replacing legacy Java EE application servers with microservices and containers

18:39 Friday, September 16, 2016 Posted by Test No comments:
, ,
Lightbend recently ran a survey with more than 2000 JVM developers and the results just got published. The survey was launched to discover:  correlations between development trends and IT infrastructure trends, how organizations at the forefront of digital transformation are modernizing their applications, and real production usage break-downs of today’s most buzzed about emerging developer technologies. While you can download the complete results from the official website, I would love to highlight some particular things that I found very interesting. Especially around containers and microservices.

Lightweight Containers Are Democratising Infrastructure and Challenging the Old Guard Java EE App Servers
The momentum around containers has gone much more quickly than many anticipated. People are looking at containers as that great hope for infrastructure portability that they’ve been chasing for a long time. And I was always interested in learning about how containers are actually used by developers in the wild. And bottom line is, that containers are really happening in production right now. What types of applications are people putting in containers is the million dollar question. Today it’s primarily greenfield applications, with far fewer examples of legacy applications being modernized for containers in production. This is the reason, that everybody is looking for more leightweight approaches to run their applications on the JVM without the overhead of Java EE servers. The survey has more details around which kind of containers and orchestration models.

Microservices and Fast Data Are Driving Application Modernization Efforts
Microservices-Based Architectures advocate the creation for a system build from a collection of small, isolated services, each of which owns their data, and is independently isolated, scalable and resilient to failure. Services integrate with other services in order to form a cohesive system that’s far more flexible than legacy monolithic applications. But how is this taken into production? Are people already building those systems or is this just a hype? Almost three third of the respondents run a microservice based system in production. And as I've been talking about in my talks before, the driver is mostly the need for real time data handling and streaming requirements.

The survey reveals a lot more details and I strongly suggest, that you look at the details of it. One thing is for sure, the changing requirements put on today's architectures can't be easily meet by just creating new applications on old platforms. And even Java EE is starting to adopt those new principles as JavaOne will hopefully how in a couple of days. I keep you posted.

Wednesday, August 31, 2016

Join me for the Reactive Microservices Roadshow

10:00 Wednesday, August 31, 2016 Posted by Test No comments:
, ,
What are the benefits of the Reactive Manifesto and the Microservices approach, especially for those who want to fundamentally modernize their business? I will discuss this at the free event „Reactive Microservices Roadshow“, on 28th September in Berlin. The event is hosted by codecentric AG and Lightbend. There will be three talks which walk you through the most important parts.



Reaktive Mircroservices with Akka (Heiko Seeberger)
The Reactive Manifesto defines essential qualities which modern systems need to have in order to cope with today's requirements: Responsiveness, which is the cornerstone of usability and utility, requires resilience and elasticity; all of these are based upon asynchronous messaging. In this talk we look at the meaning of "Reactive" for a microservice architecture, for individual services and for their collaboration.

AutoScout24 goes Microservices (Christian Deger)
Fed up with stop and go in your data center? Why not shift into overdrive and pull into the fast lane? Learn how AutoScout24, the largest online car marketplace Europe-wide, are building their Autobahn in the cloud.
Reinventing themselves by making a radical transition from monoliths to microservices, from .NET on Windows to Scala on Linux, from data center to AWS and from built by devs and run by ops to a DevOps mindset.

One microservice is no microservice—they come in systems! (Markus Eisele)
Building a complete system out of individual Microservices is not as simple as we're being told. While Microservices-based Architecture continues to draw more and more attention we're also starting to learn about the trade-offs and drawbacks. Individual Microservices are fairly easy to understand and implement, but they only make sense as systems, and it is in-between the services that the most challenging (and interesting) problems arise—here we are entering the world of distributed systems.

Find a German event description on the codecentric.de website. Looking forward to interesting discussions! Make sure to REGISTER for FREE TODAY!

Lightbender at JavaOne 2016

07:20 Wednesday, August 31, 2016 Posted by Test No comments:
,
It's only short 16 days until the Java community is starting to travel to San Francisco again. The annual family gathering at JavaOne is the place to be and it's time to get a little excited about attending once again. This year, Lightbend is a bronze sponsor and I am excited to be one of the featured speakers! A lot is going to happen during the week and you have to plan your schedule accordingly to get the most out of it.

A must attend are the sessions by Lightbend engineers.

Monitoring Reactive Microservices [CON1091] with Henrik Engström (@h3nk3)
Tuesday, Sep 20, 4:00 p.m. - 5:00 p.m. | Parc 55—Market Street
Reactive applications are the next major evolution of the internet. They allow for applications to be responsive, scalable, and resilient by building on a fully event-driven foundation. However, at the same time, this way of architecting systems introduces some new issues. One of these issues is how to monitor this type of system. This session covers the traditional monitoring approach and different ways to monitor asynchronous applications and finally looks at the way Lightbend has chosen to build a monitoring tool for reactive applications. After this presentation, developers will have a better understanding of how to monitor microservices in a reactive architecture.

End-to-End Reactive Streams, from Socket to Business [CON1852] with Konrad Malawski (@ktosopl)
Thursday, Sep 22, 11:30 a.m. - 12:30 p.m. | Hilton—Continental Ballroom 1/2/3
The Reactive Streams specification, along with its TCK and various implementations such as Akka Streams, is coming closer and closer with the inclusion of the RS types in JDK 9. Using an example Twitter-like streaming service implementation, this session shows why this is a game changer in terms of how you can design reactive streaming applications by connecting pipelines of back-pressured asynchronous processing stages. The presentation looks at the example from two perspectives: a raw implementation and an implementation addressing a high-level business need.

Stay Productive While Slicing Up the Monolith [CON6472] with myself (@myfear)
Tuesday, Sep 20, 11:00 a.m. - 12:00 p.m. | Parc 55—Mission
With microservices-based architectures, developers are left alone with provisioning and continuous delivery systems, containers and resource schedulers, frameworks and patterns to slice monoliths. How to efficiently develop them without having to provision complete production-like environments locally by hand? How to run microservices-based systems on local development machines, managing provisioning and orchestration of hundreds of services from a command-line tool without sacrificing productivity enablers. New buzzwords, frameworks, and hyped tools have made Java developers forget what it means to be productive. This session shows how much fun it can be to develop large-scale microservices-based systems. Understand the power of a fully integrated microservices development environment.

One Microservice Is No Microservice: They Come in Systems [CON6471] with myself (@myfear)
Wednesday, Sep 21, 1:00 p.m. - 2:00 p.m. | Parc 55—Embarcadero
Building a complete system out of individual microservices is hard. Microservices-based architecture is gaining attention, but there are trade-offs and drawbacks. Individual microservices are fairly easy to understand and implement, but they make sense only as systems; it’s between services that the most-challenging problems arise—in distributed systems. Slicing a system into REST services and wiring them back together with synchronous protocols and traditional enterprise tools means failure. This session distills the essence of microservices-based systems and covers a new development approach to microservices that gets you started quickly with a guided, minimalistic approach on your machine and takes you to a productive scaled-out microservices-based on the Oracle Cloud system with hundreds of services.

The Cloud-Natives Are RESTless [CON2514] Panel session with Konrad Malawski (@ktosopl)
Wednesday, Sep 21, 8:30 a.m. - 9:30 a.m. | Parc 55—Powell I/II
Representational State Transfer—the REST architecture—has served us well for the past 15 years as a style of cross-language distributed computing that is web-friendly. REST is simple and cacheable and is implemented over the original protocol for the web, good ole HTTP. For many use cases, the synchronous, request/response nature of REST fits perfectly. What are the alternatives to REST for event-based Java microservices? What reactive frameworks should Java developers learn and use in their services and overall application architecture? What synchronous cross-language alternatives should Java engineers use for high-performance, non-HTTP distributed computing in 2016 and beyond? Attend this session to find out.

I am looking forward to meet all the amazing peers from the Java Community! Find more information on the official JavaOne website and on the JavaOne blog and make also sure to follow @JavaOneConf on Twitter. And also don't forget to follow @myfear and @lightbend for more fun and games and raffles and stuff during JavaOne!

Friday, August 5, 2016

Remote JMS with WildFly Swarm

09:16 Friday, August 5, 2016 Posted by Test No comments:
, ,
I'm blogging about WildFly swarm again? Short version is: I needed a test for remote JMS access and refused to setup something complex like a complete application server. The idea was to have a simple WildFly Swarm application which has a queue and a topic configured. Both should be accessible remotely from a standalone Java application. While the topic receives messages a Message Driven Bean (MDB) dumps the output to the console. The queue is filled with random text+timestamp messages by a singleton timer bean.
Turned out, that WildFly Swarm can do it, but for now only in the snapshot release.

The code
Find the complete code on my GitHub repository. It's not the most beautiful thing I have written but it actually shows you the complete configuration of Swarm with the relevant security settings, and the construction of the queue and the topic. In short the MessagingFraction needs the relevant security settings with remote access enabled and it also needs to define the remote topic. The NamingFraction needs to enable the remote naming service and finally the ManagamentFraction needs to define authorization handler.

How to run the example
To run the server, you can just use 'mvn wildfly-swarm:run' after the startup, you see the timer bean starting to emit messages to the queue:

2016-08-05 08:44:48,003 INFO  [sample.SampleQueueTimer] (EJB default - 5) Send: Test 1470379488003
2016-08-05 08:44:49,005 INFO  [sample.SampleQueueTimer] (EJB default - 6) Send: Test 1470379489005

If you point your browser to http://localhost:8080/ you can trigger a single message being send to the topic. This also get's logged to the console:

2016-08-05 08:44:36,220 INFO  [sample.SampleTopicMDB] (Thread-250 (ActiveMQ-client-global-threads-859113460)) received: something

The real magic happens, when you look at the standalone Java client. It performs the relevant JNDI lookups and creates the JMS connection with user and password, the session and the producer and finally produces and sends a text message.
More about the "why the hell does he needs Java EE again" in some upcoming blog posts ;)

Credits
A super big thank you goes out to Ken Finnigan who fixed the issue I ran into literally over night!