Peter Lowry: “The biggest difficulty is understanding the methodology”



    September 17 in Kiev will host the conference IT NonStop Java Craft . Her special guest will be Peter Lowry, founder of the Performance Java User's Group and Java Chronicle open-source library, creator of the Vanilla Java blog . In Kiev, he will give two presentations, and on the eve of the speeches he will hold a workshop on 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 fashionable 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 is committed to positioning JavaEE in advance to take advantage of 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 Reactive Flow Control support in the new Flow API as part of its multi-threading package.

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

    - Functional models change the way you create and configure data streams. 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 reactive programming model will increase, although I suspect that this will happen gradually.

    - Now microservices are very popular. It seems that literally everyone is trying to use this approach. Do you think that soon the architecture of microservices will dominate even in 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, however, the tools that are best suited for large-scale applications are unlikely to find wide application in this segment.

    The greatest influence of microservices is noted in the following areas:
    - asynchronous messaging to improve throughput (compared to synchronous exchange);
    - private data sets (compared to distributed sets); which is a significant test for databases that act as a centralized repository of all application objects and their states.

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

    - Using each methodology and tools that microservices offer can be more complicated than creating a “monolith”. However, if you use a set of tools that can satisfy 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 perfectly tuned teamwork. The use of microservices in itself dictates the need to divide the work into sections.

    About frameworks


    “When it comes to testing reliability and performance, there are additional challenges.”

    - The way you deploy the application should not play a big role if you test it according to the black box strategy.
    If you are testing on the white box strategy, microservices are good because they help set clear boundaries for checking timings.
    From the point of view of reliability, problems can arise with a large number of elements, but simpler services can be tested individually.

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

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

    About assembly tools


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

    - Maven and Gradle support multi-module development. 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 the appropriate knowledge can you determine which testing tools are appropriate for your particular situation.

    Often, developers begin to actively use new fashionable tools and only later find really reasonable 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 become the optimal solution to your problem. In one situation, the time spent learning new tools justifies itself, in another it doesn’t.

    » Read more about the conference the NonStop Java Craft of IT
    " Tickets for the conference
    " Tickets for Peter Lowry workshop in Kiev Java 8 in Depth

    Also popular now: