System Design

System Design

Spring Application Deployed with Kubernetes

Step by step building an application using Spring Boot and deployed via Docker on Kubernetes with Helm

full course
  1. Setup: IDE and New Project
  2. Create the Data Repository
  3. Building a Service Layer
  4. Create a REST Controller
  5. Logging, Tracing and Error Handling
  6. Documentation and Code Coverage
  7. Database as a Service
  8. Containerize the Service With Docker
  9. Docker Registry
  10. Automated Build Pipeline
  11. Helm for Deployment
  12. Setting up a Kubernetes Cluster
  13. Automating Deployment (for CICD)
  14. System Design
  15. Messaging and Event Driven Design
  16. Web UI with React
  17. Containerizing our UI
  18. UI Build Pipeline
  19. Put the UI in to Helm
  20. Creating an Ingress in Kubernetes
  21. Simplify Deployment
  22. 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.

First Steps

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 CustomerDAO:

Optional<CustomerEntity> findByEmail(String email);

This is spring’s JPA convention. By using their method naming convention spring can generate the JPQL for you.

0 comments on “System DesignAdd yours →

Leave a Reply

Your email address will not be published. Required fields are marked *