Spring Application Deployed with Kubernetes
Step by step building an application using Spring Boot and deployed via Docker on Kubernetes with Helmfull course
- Setup: IDE and New Project
- Create the Data Repository
- Building a Service Layer
- Create a REST Controller
- Logging, Tracing and Error Handling
- Documentation and Code Coverage
- Database as a Service
- Containerize the Service With Docker
- Docker Registry
- Automated Build Pipeline
- Helm for Deployment
- Setting up a Kubernetes Cluster
- Automating Deployment (for CICD)
- System Design
- Messaging and Event Driven Design
- Web UI with React
- Containerizing our UI
- UI Build Pipeline
- Put the UI in to Helm
- Creating an Ingress in Kubernetes
- Simplify Deployment
- Conclusion and Review
We’ve successfully deployed a service and confirmed that its accessible. However, a single service doesn’t make an app. We now need to fill out the rest of the application and introduce some best practices around service governance and system engineering.
The Application Design
We’re going to be organizing the UI as microUI applications that interact directly with services specific to their function. This will give us flexibility in terms of evolving our enterprise application functionality. Additionally, each service will publish a message reflecting a change to the state of the data maintained by that service.
We will be able to move between UI application contexts because we’ll be using OAuth and will configure our application to recognize the token across contexts.
We’re going to be using our initial service as a template for the new development. However, even though we’ve done a lot of work here to get it into a ‘good’ place, there are still some gaps that we’ll want to patch before we use it as a good example.
Validate Customer Existence
We knew that we are not handling duplicate customer creation requests consistently across platforms (different databases handle the request differently). We want to manage this better with this flow:
Return Existing Customers
We probably also want the ability to return a single user as well as a list of all users. So we want to add these flows as well:
Implementing all of this should be fairly straightforward based on our current codebase. The only thing that is unique is the updates to
Optional<CustomerEntity> findByEmail(String email);
This is spring’s JPA convention. By using their method naming convention spring can generate the JPQL for you.