Peter Lowry: “The greatest difficulty is in understanding the methodology”

September 17 in Kiev will host the IT NonStop Java Craft conference. Her special guest will be Peter Lowry, founder of the Performance Java User's Group and the Java Chronicle open-source library, the creator of the Vanilla Java blog. In Kiev, he will give two presentations, and on the eve of his speeches he will be led by a workshop dedicated to Java 8. DataArt talked with Peter about the present and near future of the Java ecosystem, the popularity of microservices, and the main problems of modern technologies.

About architecture

- Java 8 has taken a huge step toward the reactive programming model. The latest version of Spring also supports some of its elements. What, in your opinion, will be the next set of best practices for developing applications for large enterprises?
')
- Oracle in advance seeks to properly position JavaEE in order to take advantage of the benefits provided by microservices and reactive programming. We will hear about the company's plans very soon, at the upcoming annual JavaOne conference. In particular, Java 9 will receive support for Reactive Flow Control in the new Flow API as part of a package for working with multithreading.

- To what extent will the new features of functional and reactive programming affect the software development process for corporations?

- Functional models change the way you create and configure data flows. I think that in the future we will see fewer configurations in XML or JSON formats and more configurations created programmatically using Java.
The importance and popularity of the model of reactive programming will increase, although I suspect that this will occur gradually.

- Now microservices are very popular. It seems that literally everyone is trying to use this approach. Do you think that soon microservice architecture will dominate even relatively small projects?

- Microservices are a set of best practices in development. They support several independently deployable components. I am sure that the most effective of these development tools will dominate even in small projects, but the tools that are best suited for large-scale applications are unlikely to be widely used in this segment.

The greatest impact of microservices is noted in the following areas:
- asynchronous messaging to improve throughput (compared to synchronous exchange);
- private data sets (compared to distributed sets); This is a significant challenge for databases that play the role of centralized storage of all application objects and their states.

- Developing an application using the microservice architecture is usually somewhat more complicated than implementing a monolithic application.

- The use of each methodology and tools that microservices offer may be more difficult than creating a "monolith". However, if you use a set of tools that can meet your needs, decomposing the application into separate components with a clear business goal for everyone will help make your product easier. You can implement it as a monolithic application, but for this you need a perfectly established teamwork. The use of microservices in itself dictates the need to divide the work into sections.

About frameworks

“When it comes to reliability and performance testing, additional difficulties arise.

- The way you deploy an application should not play a big role if you are testing it with a black box strategy.
If you are testing the strategy of the white box, microservices are good because they help to establish clear boundaries for timing checks.
From the point of view of reliability, problems may arise with a large number of elements, but at the same time, simpler services can be tested individually.

- Do you think that additional frameworks (or extension of existing ones) are needed, which will simplify microservice tests and / or check performance, latency, etc.?

- I'm not a big fan of frameworks. We have a methodology for profiling end-to-end key interactions by adding highly accurate performance counters. In the past, there were no clearly defined places for these meters. In the case of monolithic applications, I would use the places associated with each event of writing data and reading a message. If your services are about the same size, this is a good start. Subsequently, you can add other counters as needed.

About build tools

- Do the existing tools for automatic assembly (Maven, Gradle) support the microservice development cycle?

- Maven and Gradle support development with a variety of modules. Most likely, you will have a module for each class of microservices (or multiple occurrences of the same service), where Maven / Gradle can be expanded to test microservices and deploy through continuous integration.

- What is worth improving today?

- The biggest difficulty is in properly understanding the problems and methodologies. Only with relevant knowledge can you determine which testing tools are appropriate for your particular situation.

Often, developers are beginning to actively use new fashionable tools and only later find really sensible use for them. For example, when using Docker, there is a great danger that you invest time in studying it, and the tool will not be the best solution to your problem. In one situation, the time spent exploring new tools justifies itself; in the other, it does not.

» Read more about the IT NonStop Java Craft conference
» Conference Tickets
» Tickets for Peter Lowry's workshop in Kiev Java 8 in Depth