At CHP Consulting we work in an agile way to develop our asset finance software platform, ALFA Systems, a web application built in Java. We work iteratively, release often, practise continuous integration and test-driven development, and communicate a lot.
It’s this way of working that takes us to some of the world’s top technology conferences (in not inconsiderable numbers), such as QCon, JavaOne and most recently Devoxx UK 2016, the Java community conference they like to say is by developers, for developers.
At Devoxx we identified four dominant themes from over 100 conference sessions, hands-on labs, Ignite talks and informal discussions over the three days. Read our takeaways below.
Version 8 of Java has been available for a little over two years now, and many of the Devoxx sessions discussed the benefits and potential pitfalls of its use.
Some of Java 8’s new features, particularly lambdas and streams, provide great opportunities for creating a more readable codebase, and therefore a more maintainable one. However, there is a danger that such features could be seen as a golden hammer. Those who take up these features must be wary of using them prudently.
Opinions were divided as to what extent applications that use older versions of Java should be refactored in order to use these new language features, with some advocating a complete refactor of the codebase and others suggesting a more cautious or nuanced approach. Despite these differences, there was a general agreement that organisations who want to switch their application to using Java 8 language features should create a common set of guidelines and best practices that they can follow internally.
The term microservices describes a software architecture pattern that arose from the move of some applications to a model of continuous deployment. Under such a pattern, each service is responsible for a small and discrete piece of functionality, and can be deployed or removed from the application individually. Microservices are useful to organisations who constantly move code from development to production, hundreds or thousands of times a day.
The alternative is to redeploy the entire application each and every time there is new code, which results in large amounts of downtime, especially if when redeploying many times a day. Such monolithic applications and their deployment requirements can be unacceptable for applications such as Amazon or Netflix, who are required to provide constant availability.
Moving an application from a monolithic architecture to one based on microservices was hotly debated. Many see microservices as the only direction for software to take in the future, and believe that monoliths should be broken up. However, for applications that don’t work on a continuous deployment model, the benefits of microservices are less certain, and the effort required for the refactor could be unnecessarily large.
If breaking up your monolithic application into microservices will prove costly and time-consuming, as is likely, some of the benefits of microservices can be realised by making the architecture of the monolithic application more modular instead.
Splitting your application into modules that have well defined responsibilities and potential connections will make it both more maintainable and functionally scalable. Furthermore, a monolith broken up in this way could more easily be refactored to become microservices-based if required in the future.
Slated for Q1 2017, Java 9 will introduce features that allow the modularity of code within an application to be defined more strictly. The advantages to refactoring monolithic applications so that the new features in Java 9 can be quickly adopted are clear.
CHP’s enterprise software application has always been designed to scale appropriately with the business. At Devoxx, plenty of thought was also put into how to scale the software organisations themselves. A number of techniques for increasing organisation scalability were presented:
Two key themes linked all of the organisational scalability presentations. The first was that experimentation is key; all software-based organisations must experiment with different techniques, work out what works for them, drop what doesn’t work, and promote what does. We must foster a climate of innovation, where experimentation is encouraged, monitored, and recorded.
The second theme is that more employees must be included in more of the decision-making process, and empowered to make decisions of their own. In order to produce the best work in the complex world of software engineering, a ‘command-and-control’ style organisation will not flourish, as these organisations do not promote the understanding and buy-in that developing software requires.
CHP clients choose ALFA because it’s portable, easy to deploy, and scalable. It uses best-in-class open-source Java components and lets our clients use a range of database platforms and application servers. But we can only continue to provide our clients with our products and services by making use of the expertise and innovation that continues to fill the industry. Thanks Devoxx, and roll on, JavaOne.