What are “modern applications”?

We say we develop modern applications. We do application modernisation. What exactly does Remiges mean by this?

The tech stack

Our team has worked with the following language systems at various points in our journey:

• Perl: CGI, FastCGI
• NodeJS
• dotNet
• Java: servlets, JSP, Struts 2, Springboot
• PHP: Code Igniter, Laravel
• Go

We do not build what we call modern applications unless we work with a tech stack which we have full tooling for. This means Java Springboot or Go/Gin only.

For mobile applications, we have worked with native code but we do not do this any more. We only work with Ionic (on a Capacitor framework), Flutter, or React.

So for a modern application, we first have to zero in on the tech stack.

The platform

We write code using our libraries and platform. We have built Remiges Alya to offer all the subsystems, all the standardisation, security and reliability which we wish to offer. This is a massive investment, and we cannot reinvent this platform at will. Remiges Alya is only available on Go/Gin and Java Springboot.

Working with Alya is not a huge change for the programmer — he continues to work at some level with either the Java Springboot or the Go/Gin environment. He just begins to feel that his work is reduced, because there are ready-made libraries and subsystems which offload a lot of his work.

Thus, our development platform delivers more reliable projects in less time. Therefore, we build modern applications only on our development platform, Alya.

The build system

We build modern applications with build and deployment automation. This sounds like a not-so-modern idea, but it’s not common in the world of custom software systems for large enterprises.

We use a Jenkins-based build toolset, which incorporates static code analysers and aborts the build if code quality does not pass muster. These code analysers can also be run by hand, of course, but are never used regularly in practice unless the build pipeline enforces these quality gates.

So, our automated build process delivers faster builds, error-free deployment, and better code quality. All our modern applications use automated build-deploy systems.

It’s all contained

We use containers as an architecture strategy for all modern projects. The older style of deployment brought in too many uncertainties and dependencies.

• When deploying a traditional application on traditional servers, various files and directories have to be purged, then fresh files and directories need to be created with the right permissions and the right ownerships, then binaries need to be copied into the right places, various daemons need to be started up, their configurations need to match the version of application just deployed, and so on. With containers, your automated build system just builds the container image and keeps it in the archive, and Kubernetes just picks it up. The entire deployment dance is gone.
• With traditional applications, the version of the binary must match the versions of various tools, configuration files, and shared libraries. If you upgrade the OS distribution, it’s possible that you may have to rebuild the application with the latest libraries and tools, to ensure stable operation. Containers are far more self-contained.
• If a traditional server is broken into and some trojans or rootkits are installed, then detecting and removing them is a big and uncertain exercise. With containers, you just shut down the current container instance and reload from its image. You are sure that all malware is gone.
• Containers are so much lighter and smaller than VMs. For most situations, VMs appear to be overkill for business application code.

We now work only with containerised architectures and happily set it up for our clients.

A separate IAM service

All modern applications use an industry-standard IAM (Identity and Access Management) system which works as a separate service in a separate container. We build with Remiges IDshield, our open source product which is itself an extension of the famous open-source Keycloak system.

The login screen for all our applications are generated from IDshield. Support for 2FA, third-party identity services, self-service password resets, are all provided out of the box. IDshield also has advanced authorization features, geo-IP restrictions for access, 2FA over SMS, etc. Most important: IDshield complies with a whole range of modern security standards and protocols which address the urgent challenges of more recent threat vectors. And since IDshield implements a JWT-based session, it is horizontally scalable.

All our modern applications use IDshield or a similar IAM service.

The logs and the metrics

All modern applications do detailed logging in a centralised repository out of the box, thanks to our open source product, Remiges LogHarbour. This product maintains three separate logs:

• debug logs for debugging, used only by programmers
• activity logs to monitor system activity, accesses, and errors
• data-change logs to address the CDC issue and provide a platform for forensic traceability

This product, integrated into the application, closes the issue of detailed insights from the running system. The second problem is one of timings, volumes, and counts: metrics from the innards of the application. One of the commonest challenges with legacy applications is the complete opaqueness in view of performance chokes or occasional rate jitter in throughput. In such cases, there is no instrumentation within the application to report the rate of web services, the latencies of specific SQL statements, etc. With modern applications, we address this by integrating our open source product, Remiges ServerSage, into the application. Extremely high performance agents collect metrics with near-zero overheads and the monitoring servers of ServerSage pull them out to show trends over time, progressive worsening of health parameters, spikes and dips, etc. Alerts can also be generated automatically.

These two products ensure that no modern applications run blind, no application management team is left groping in the dark when things don’t behave in expected ways.

The awesome good looks

We have gone through a process of deep investigation and self-analysis about what makes for good UX and UI. We have arrived at the final conclusion that good UX operates at two levels:

• the more sensitive and deeper levels which are specific to each application and each persona who uses it
• the more general levels where every application can benefit from a standard set of guidelines about what makes an ordinary application very clean, systematic and friendly

We work intensely on the first point for larger applications to arrive at a custom-designed UX, and have codified a set of guidelines which help us at the more general levels. Our applications follow most of the rules of excellent UX straight out of the box even without application-specific refinements. The net result is a modern, light, understated “look” which gets out of the way and allows the user to do what he needs with the minimum fuss. All our modern applications get the benefit of our UX and UI excellence.

In summary

Modern applications done the Remiges way:

• are built on modern tech stacks to gain all the compatibility, performance and stability advantages of recent technology, not to speak of great UI
• deliver fast development times, cleaner code due to tooling, more agile time-to-market, tight security and unprecedented scalability
• allow the application to monitor itself and offer insights into its internal operations to great depth

It makes sense to modernize.