End to End Java on Azure, Episode 1: Introduction and Context

Mark Heckler

I’m excited to announce an idea that that came to me late last year and that I’m making official now: over the next several weeks, I’ll be building – and sharing – a distributed system of applications to show off some incredibly cool and useful things developers can do with Spring Boot, Java, and various parts of the Azure ecosystem, working together in production environments for critical workloads.

There are so many tools at a developer’s fingertips that it just seemed wrong to explore them without sharing them. The plan is to put them all together in an evolving and expanding system portfolio and document the journey with articles, long- and short-form videos, and…perhaps more.

The system will evolve even while this series unfolds, intentionally and deliberately. As with every real-world system, there will be changes along the way: adaptations to fit circumstances and the greater understanding gained while expanding our system’s universe.

 

Series Premise

True green field solutions are rare. In most cases, we developers “arrive at the scene” with some applications already in place performing some essential tasks. Unless we’re addressing something that isn’t working as intended, we’re working in the gaps: creating functionality to address requirements that have not yet been met, either within existing applications or in the vacant application space between them.

Just as 100% green field systems are rare, so are application islands. Integration is key to achieving most goals, as we don’t – can’t – just roll in and replace several key (working) applications when creating additional functionality that lies somewhere between them all.

Even if we do get the opportunity to start with a blank slate, the outcome is nearly always the same, it just takes a bit longer to get there: we create multiple applications to fulfill pressing requirements demanded by our community and/or customers, deploying desperately needed functionality as quickly as we can. As more critical applications come online and our understanding of the (numerous) problem domains increase, we adjust course and refactor accordingly…bringing us back to this series.

 

The Plan

I plan to develop a series of applications and deploy them to a production environment using tools that support effective development, deployment, and production-ready operation. It’s impossible to exhaustively cover every possible tool, library, and platform option in a series of any reasonable length, but I’ll put employ several to create a representative example of a typical developer workflow over a period of time and across a portfolio of requirements.

 

Initial Architecture

This is the initial, high-level plan for our new system’s architecture. As mentioned earlier, details will be added and changed as the series unfolds and the domain is both better-understood and -defined – just as would occur in the real world.

Initial target architecture for series

 

The Agenda

First, I’ll start by developing a news supplier application that polls an external news clearinghouse for desired topic(s) and retrieves relevant articles. I intend to use Azure Cosmos DB to store those articles for reference, and I’ll leverage Azure Key Vault for secure storage of secrets to enable the implementation of a passwordless connection between app and database. I plan to deploy the news supplier app and related infrastructure to Azure App Service using Terraform and/or other widely available option(s).

Second, I’ll extend the news supplier app to send newly retrieved articles to a pipeline (queue/topic in other parlance) for retrieval and use by future applications. In many cases, one might choose instead to build consuming app(s) prior to (pre)filling the pipeline, but since we know what is planned next, we can be a bit more flexible with order.

Third up is the email notification application. Azure Communication Services (ACS) provide both email notifications and the posting of updates to Teams channels, so knowledge we pick up from one app should shorten the development cycle for the other.

Fourth, I’ll develop the Teams posting application, once again pressing ACS into service. I don’t expect this installment to be quite as exhaustive as the previous one, as many concepts will parallel (Beware overly optimistic expectations!), so it may be a bit shorter and/or information dense than preceding ones.

Finally, as the pièce de résistance, I’ll develop an application to expose a Really Simple Syndication (RSS) API for use by RSS reader apps. After Google killed Google Reader (may it rest in peace), many turned to Twitter as an approximate substitution for news feed-like topical information streams. Due to recent developments at Twitter, many are rediscovering the utility of RSS as a no-noise news aggregator.

 

Planned Technologies

  • Visual Studio Code, GitHub Copilot
  • Spring Boot (JVM-based, native image, and containers) and Java
  • Terraform, az cli, GitHub Actions
  • Azure Key Vault, Azure Cosmos DB, Azure App Service, Azure Container Apps, Azure Spring Apps, Event Hubs, Azure Communications Services, and ???

 

Multimedia

Articles (like this one!), plus long- and short-form videos. Code repos. Maybe some livestreams. Stay tuned, you never know what we’ll come up with and you won’t want to miss it!

 

Summary

By the end of this series, developers should have a greater understanding of how to leverage Spring Boot and Java, force-multiplying developer tools, and best in category Azure infrastructure components and deployment options to build and deploy to production faster and better than ever. Thanks for coming with me on this amazing ride!

0 comments

Discussion is closed.

Feedback usabilla icon