Parallel Agile announced a new version of CodeBot, a low-code MERN stack application generator.
The 2020 Java Developer Productivity Report, carried out by Perforce Software, received detailed responses from nearly 400 Java development professionals (with 74% identifying themselves as developers) worldwide. If there was one message that stood out loud and clear it was this: microservices are growing fast, but bring considerable new challenges for developers.
The survey found over 50% of respondents already using microservices, with 28% still working in the monolith environment. 10% reported working in SOA-based architectures, with the remainder spread across desktop, mobile, and serverless application architectures.
Nearly two-thirds of respondents reported working in, or in the process of transitioning to microservices, with a further 21% considering microservices adoption. That means a combined 85% of those surveyed are working with, or considering, microservices for their current project.
Challenges With Microservices
Microservices adoption may have outpaced expectations, but this architectural sea-change carries new challenges for application performance.
Performance issues were the biggest challenge cited by survey respondents, with 29% experiencing problems trouble-shooting inter-service performance, and 33% experiencing performance issues in the overall distributed system. The top performance issue reported by 55% of respondents was slow application response time, followed by memory leaks at 28% and excessive open connections at 24%.
The next biggest issue reported was setting up the local development environment, at 41%, due to this being an intricate, difficult and time-intensive process. This was closely followed by trouble-shooting of inter-service functionality (38.85%).
One prominent concern for developers was their visibility into how their microservices work together as a system. Developers rated their satisfaction with code visibility at only six out of ten.
New Architecture, New and Old Problems
Beyond microservices, at 70%, developers are being asked to have far greater responsibility for application performance. Over half reported non-functional performance goals, which, in practice, means they are carrying out more application performance tests, but often without full insight into how their code is impacting the rest of the application.
This may be a contributing factor to why the survey also found that over 78% of teams had issues that reached production stage in the previous 12 months, though only 17% said that had happened regularly. The good news is the 21% who did not experience issues escaping into production.
Redeploys are another pain point for developers. With the average Java developer reportedly deploying code ten times per day, lengthy redeploys can cause significant roadblocks during development. In fact, almost half of all the survey respondents reported over four minutes per redeploy. (This is despite the widespread adoption of microservices, which were expected to decrease redeploy times.) A further third experience redeploy times of between two and three minutes, with only 20% fortunate enough to experience just one minute per redeploy.
With an average satisfaction rating of six out of ten, most developers were above satisfied with available microservices troubleshooting technologies. 72% of developers reported ratings of satisfied and above, with the remaining 28% less than satisfied with available troubleshooting options.
The popularity of microservices-ready (or requisite) technologies like Docker, Spring Boot and IntelliJ IDEA showed the impact of microservices on the Java development technology landscape. Spring Boot claimed the title for most popular runtime platform at over 80% use, while IntelliJ IDEA led IDE usage at over 81%. Docker, now synonymous with microservices, led virtualization tools usage at over 70%. Kubernetes (often used alongside Docker) represented 35% usage, while VMware and Vagrant followed with 17% and 4% usage, respectively.
While tools and technologies quickly evolve to supply the means of widespread innovation, developers still face many of the same issues.
Will new innovations solve these perennial issues? Perhaps the focus for the next decade needs to be more on how to empower developers to automate, remove, and streamline tasks for these increasingly complex applications.